Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook

[Manasi Navare]

Ville,  thanks for the patch and
Sorry for not being able to review this earlier.
Please find some comments below:

On Wed, Jan 31, 2018 at 03:27:10PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote:
> > On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Doing link retraining from the short pulse handler is problematic since
> > > that might introduce deadlocks with MST sideband processing. Currently
> > > we don't retrain MST links from this code, but we want to change that.
> > > So better to move the entire thing to the hotplug work. We can utilize
> > > the new encoder->hotplug() hook for this.
> > > 
> > > The only thing we leave in the short pulse handler is the link status
> > > check. That one still depends on the link parameters stored under
> > > intel_dp, so no locking around that but races should be mostly harmless
> > > as the actual retraining code will recheck the link state if we
> > > end up there by mistake.
> > > 
> > > v2: Rebase due to ->post_hotplug() now being just ->hotplug()
> > > Check the connector type to figure out if we should do
> > > the HDMI thing or the DP think for DDI
> > > 
> > > Cc: Manasi Navare 
> > > Cc: Maarten Lankhorst 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c |  10 +-
> > >  drivers/gpu/drm/i915/intel_dp.c  | 196 
> > > ++--
> > > ---
> > >  drivers/gpu/drm/i915/intel_drv.h |   2 +
> > >  3 files changed, 120 insertions(+), 88 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 25793bdc692f..5f3d58f1ae6e 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -2880,7 +2880,10 @@ static bool intel_ddi_hotplug(struct intel_encoder
> > > *encoder,
> > >   drm_modeset_acquire_init(, 0);
> > >  
> > >   for (;;) {
> > > - ret = intel_hdmi_reset_link(encoder, );
> > > + if (connector->base.connector_type ==
> > > DRM_MODE_CONNECTOR_HDMIA)
> > > + ret = intel_hdmi_reset_link(encoder, );
> > > + else
> > > + ret = intel_dp_retrain_link(encoder, );
> > >  
> > >   if (ret == -EDEADLK) {
> > >   drm_modeset_backoff();
> > > @@ -3007,10 +3010,7 @@ void intel_ddi_init(struct drm_i915_private 
> > > *dev_priv,
> > > enum port port)
> > >   drm_encoder_init(_priv->drm, encoder, _ddi_funcs,
> > >DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
> > >  
> > > - if (init_hdmi)
> > > - intel_encoder->hotplug = intel_ddi_hotplug;
> > > - else
> > > - intel_encoder->hotplug = intel_encoder_hotplug;
> > > + intel_encoder->hotplug = intel_ddi_hotplug;
> > >   intel_encoder->compute_output_type = intel_ddi_compute_output_type;
> > >   intel_encoder->compute_config = intel_ddi_compute_config;
> > >   intel_encoder->enable = intel_enable_ddi;
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 6bbf14410c2a..152016e09a11 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -4275,12 +4275,83 @@ intel_dp_check_mst_status(struct intel_dp 
> > > *intel_dp)
> > >   return -EINVAL;
> > >  }
> > >  
> > > -static void
> > > -intel_dp_retrain_link(struct intel_dp *intel_dp)
> > > +static bool
> > > +intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
> > > +{
> > > + u8 link_status[DP_LINK_STATUS_SIZE];
> > > +
> > > + if (!intel_dp_get_link_status(intel_dp, link_status)) {
> > > + DRM_ERROR("Failed to get link status\n");
> > > + return false;
> > > + }
> > > +
> > > + /*
> > > +  * Validate the cached values of intel_dp->link_rate and
> > > +  * intel_dp->lane_count before attempting to retrain.
> > > +  */
> > > + if (!intel_dp_link_params_valid(intel_dp, intel_dp->link_rate,
> > > + intel_dp->lane_count))
> > > + return false;
> > > +
> > > + /* Retrain if Channel EQ or CR not ok */
> > > + return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
> > > +}
> > > +
> > > +/*
> > > + * If display is now connected check links status,
> > > + * there has been known issues of link loss triggering
> > > + * long pulse.
> > > + *
> > > + * Some sinks (eg. ASUS PB287Q) seem to perform some
> > > + * weird HPD ping pong during modesets. So we can apparently
> > > + * end up with HPD going low during a modeset, and then
> > > + * going back up soon after. And once that happens we must
> > > + * retrain the link to get a picture. That's in case no
> > > + * userspace component reacted to intermittent HPD dip.
> > > + */
> > > +int intel_dp_retrain_link(struct intel_encoder *encoder,
> > > +   

Re: [Intel-gfx] [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Archit Taneja]

On Tuesday 27 February 2018 06:26 PM, Ville Syrjala wrote:

From: Ville Syrjälä 

Currently we have a mix of static and dynamic information stored in
the display info structure. That makes it rather difficult to repopulate
the dynamic parts when a new EDID appears. Let's make life easier by
splitting the structure up into static and dynamic parts.

The static part will consist of subpixel_order, panel_orientation,
and bus_formats.

Actually I'm not sure where bus_formats & co. fit in all this. For some
drivers those seem to be static, even though they might fill them out
from .get_modes(). For other drivers this stuff even gets frobbed at
runtime, making it more some kind of a bastard encoder/connector state.
I'll just stick it into the static side so that the behaviour doesn't
change when I start clear out the entire dynamic state with memset().



[...]

  
diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c

index b1ab4ab09532..abd0bce9c31e 100644
--- a/drivers/gpu/drm/bridge/sii902x.c
+++ b/drivers/gpu/drm/bridge/sii902x.c
@@ -174,7 +174,7 @@ static int sii902x_get_modes(struct drm_connector 
*connector)
kfree(edid);
}
  
-	ret = drm_display_info_set_bus_formats(>display_info,

+   ret = drm_display_info_set_bus_formats(>static_display_info,
   _format, 1);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 08ab7d6aea65..042ded9ca749 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1193,7 +1193,7 @@ static int tc_bridge_attach(struct drm_bridge *bridge)
if (tc->panel)
drm_panel_attach(tc->panel, >connector);
  
-	drm_display_info_set_bus_formats(>connector.display_info,

+   drm_display_info_set_bus_formats(>connector.static_display_info,
 _format, 1);
drm_mode_connector_attach_encoder(>connector, tc->bridge.encoder);
  


The sii902x driver sets the bus_formats in get_modes, but it's a fixed 
value and we may as well do it in bridge's attach op.


For the bridge drivers:

Reviewed-by: Archit Taneja 

Thanks,
Archit

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915: Improve PSR activation timing

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Improve PSR activation timing
URL   : https://patchwork.freedesktop.org/series/39075/
State : warning

== Summary ==

Series 39075v1 series starting with [1/3] drm/i915: Improve PSR activation 
timing
https://patchwork.freedesktop.org/api/1.0/series/39075/revisions/1/mbox/

 Possible new issues:

Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-cfl-s2)
pass   -> DMESG-WARN (fi-cnl-y3)
pass   -> DMESG-WARN (fi-glk-1)
pass   -> DMESG-WARN (fi-kbl-7560u)
pass   -> DMESG-WARN (fi-kbl-r)
pass   -> DMESG-WARN (fi-skl-6600u)

 Known issues:

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700k2) fdo#104108
Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> PASS   (fi-pnv-d510) fdo#101600
Test kms_psr_sink_crc:
Subgroup psr_basic:
pass   -> DMESG-WARN (fi-skl-6700hq) fdo#101144

fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:476s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:396s
fi-cfl-s2total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:558s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:584s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:259  dwarn:1   dfail:0   fail:0   skip:28  
time:502s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:389s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:451s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:413s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:447s
fi-kbl-7560u total:288  pass:268  dwarn:1   dfail:0   fail:0   skip:19  
time:487s
fi-kbl-r total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:490s
fi-pnv-d510  total:288  pass:223  dwarn:0   dfail:0   fail:0   skip:65  
time:560s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:260  dwarn:1   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:482s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:520s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s
fi-ilk-650 failed to collect. IGT log at Patchwork_8182/fi-ilk-650/run0.log
fi-kbl-7567u failed to collect. IGT log at Patchwork_8182/fi-kbl-7567u/run0.log

5d22ee63b365bf7e08e0c06d4c7ff62501f27477 drm-tip: 2018y-02m-28d-00h-25m-02s UTC 
integration manifest
5b51ba8b960a drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.
a3a9e922d588 drm/i915/psr: Kill scheduled work for Core platforms.
8e859ebcdb11 drm/i915: Improve PSR activation timing

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Improve PSR activation timing

[Andy Lutomirski]

On Wed, Feb 28, 2018 at 12:26 AM, Chris Wilson  wrote:
> Quoting Andy Lutomirski (2018-02-24 00:07:23)
>> On Tue, Feb 13, 2018 at 11:26 PM, Rodrigo Vivi  
>> wrote:
>> > From: Andy Lutomirski 
>> >
>> > +
>> > +   dev_priv->psr.activate_timer.expires = jiffies - 1;
>>
>> That can't possibly be okay.
>
> As an initialisation value, set to the previous jiffie? You can set it
> to the current jiffie, but then you have the issue of not noticing the
> update to the current jiffie.
>
> So how is this any more incorrect?

I don't think you can just write to fields in struct timer_list like that.
___
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: Improve PSR activation timing

[Andy Lutomirski]

On Wed, Feb 28, 2018 at 12:22 AM, Chris Wilson  wrote:
> Quoting Rodrigo Vivi (2018-02-28 00:14:08)
>> From: Andy Lutomirski 
>>
>> The current PSR code has a two call sites that each schedule delayed
>> work to activate PSR.  As far as I can tell, each call site intends
>> to keep PSR inactive for the given amount of time and then allow it
>> to be activated.
>>
>> The call sites are:
>>
>>  - intel_psr_enable(), which explicitly states in a comment that
>>it's trying to keep PSR off a short time after the dispay is
>>initialized as a workaround.
>>
>>  - intel_psr_flush().  There isn't an explcit explanation, but the
>>intent is presumably to keep PSR off until the display has been
>>idle for 100ms.
>>
>> The current code doesn't actually accomplish either of these goals.
>> Rather than keeping PSR inactive for the given amount of time, it
>> will schedule PSR for activation after the given time, with the
>> earliest target time in such a request winning.
>>
>> In other words, if intel_psr_enable() is immediately followed by
>> intel_psr_flush(), then PSR will be activated after 100ms even if
>> intel_psr_enable() wanted a longer delay.  And, if the screen is
>> being constantly updated so that intel_psr_flush() is called once
>> per frame at 60Hz, PSR will still be activated once every 100ms.
>>
>> Rewrite the code so that it does what was intended.  This adds
>> a new function intel_psr_schedule(), which will enable PSR after
>> the requested time but no sooner.
>>
>> v3: (by Rodrigo): Rebased on top of recent drm-tip without any
>> modification from the original.
>>
>> Cc: Dhinakaran Pandiyan 
>> Signed-off-by: Andy Lutomirski 
>> Signed-off-by: Rodrigo Vivi 
>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c |  9 +++--
>>  drivers/gpu/drm/i915/i915_drv.h |  4 ++-
>>  drivers/gpu/drm/i915/intel_psr.c| 69 
>> -
>>  3 files changed, 71 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 33fbf3965309..1ac942d1742e 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -2572,8 +2572,13 @@ static int i915_edp_psr_status(struct seq_file *m, 
>> void *data)
>> seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
>> seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>>dev_priv->psr.busy_frontbuffer_bits);
>> -   seq_printf(m, "Re-enable work scheduled: %s\n",
>> -  yesno(work_busy(_priv->psr.work.work)));
>> +
>> +   if (timer_pending(_priv->psr.activate_timer))
>> +   seq_printf(m, "Activate scheduled: yes, in %ldms\n",
>> +  (long)(dev_priv->psr.earliest_activate - jiffies) 
>> *
>
> msecs_from_jiffies
>
>> +  1000 / HZ);
>> +   else
>> +   seq_printf(m, "Re-enable scheduled: no\n");
>>
>> if (HAS_DDI(dev_priv)) {
>> if (dev_priv->psr.psr2_support)
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 7bbec5546d12..6e6cf2ce3749 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -764,7 +764,9 @@ struct i915_psr {
>> bool sink_support;
>> struct intel_dp *enabled;
>> bool active;
>> -   struct delayed_work work;
>> +   struct timer_list activate_timer;
>> +   struct work_struct activate_work;
>> +   unsigned long earliest_activate;
>
> Incorporated into struct timer_list, so this is redundant.

This way gives a clean way to say "don't do the work before
such-and-such time".  I don't think we can do it with mod_timer()
since the timer might already have started firing, and we can't
del_timer_sync() because there would be a lock inversion.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

[Souza, Jose]

On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza
> wrote:
> > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > self, so lets use the mutex register that is available in gen9+ to
> > avoid concurrent access by hardware and driver.
> > Older gen handling will be done separated.
> > 
> > Reference: https://01.org/sites/default/files/documentation/intel-g
> > fx-prm-osrc-skl-vol12-display.pdf
> > Page 198 - AUX programming sequence
> > 
> > Reviewed-by: Dhinakaran Pandiyan 
> > Reviewed-by: Rodrigo Vivi 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> > 
> > Changelog:
> > v2
> > - removed the PSR dependency, now getting lock all the times when
> > available
> > - renamed functions to avoid nested calls
> > - moved register bits right after the DP_AUX_CH_MUTEX()
> > - removed 'drm/i915: keep AUX powered while PSR is enabled'
> > Dhinakaran Pandiyan will sent a better and final version
> > v3
> > - rebased on top of Ville's AUX series
> > - moved port registers to above DP_AUX_CH_MUTEX()
> > - using intel_wait_for_register() instead of the internal version
> > v4
> > - removed virtual function to get mutex register address
> > - enabling the mutex back only on aux channel init
> > - added the aux channel name to the timeout debug message
> > v5
> > - renamed DP_AUX_CH_MUTEX() parameter to aux_ch
> > - renamed goto label when intel_dp_aux_ch_trylock() fails
> > 
> >  drivers/gpu/drm/i915/i915_reg.h |  9 
> >  drivers/gpu/drm/i915/intel_dp.c | 47
> > +
> >  2 files changed, 56 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index eea5b2c537d4..bce2e6dad4c4 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5385,6 +5385,15 @@ enum {
> >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> >  
> > +#define _DPA_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6402C)
> > +#define _DPB_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6412C)
> > +#define _DPC_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6422C)
> > +#define _DPD_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6432C)
> > +#define _DPF_AUX_CH_MUTEX  (dev_priv-
> > >info.display_mmio_offset + 0x6452C)
> > +#define DP_AUX_CH_MUTEX(aux_ch)_MMIO_PORT(aux_ch,
> > _DPA_AUX_CH_MUTEX, _DPB_AUX_CH_MUTEX)
> > +#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
> > +#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
> > +
> >  /*
> >   * Computing GMCH M and N values for the Display Port link
> >   *
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 2a3b3ae4e3da..7f4bf77227cd 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1081,6 +1081,42 @@ static uint32_t
> > intel_dp_get_aux_send_ctl(struct intel_dp *intel_dp,
> > aux_clock_divider)
> > ;
> >  }
> >  
> > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port =
> > dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(intel_dig_port->base.base.dev);
> > +
> > +   if (INTEL_GEN(dev_priv) < 9)
> > +   return true;
> > +
> > +   /* Spec says that mutex is acquired when status bit is
> > read as unset,
> > +* here waiting for 2msec(+-4 aux transactions) before
> > give up.
> > +*/
> > +   if (intel_wait_for_register(dev_priv,
> > DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> > +   DP_AUX_CH_MUTEX_STATUS, 0, 2))
> > {
> > +   DRM_DEBUG_KMS("aux channel %c locked for 2msec,
> > timing out\n",
> > + aux_ch_name(intel_dp->aux_ch));
> > +   return false;
> > +   }
> > +
> > +   return true;
> > +}
> > +
> > +static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port =
> > dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(intel_dig_port->base.base.dev);
> > +
> > +   if (INTEL_GEN(dev_priv) < 9)
> > +   return;
> > +
> > +   /* set the status bit releases the mutex + keeping mutex
> > enabled */
> > +   I915_WRITE(DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> > +  DP_AUX_CH_MUTEX_ENABLE |
> > DP_AUX_CH_MUTEX_STATUS);
> > +}
> > +
> >  static int
> >  intel_dp_aux_ch(struct intel_dp *intel_dp,
> > const uint8_t *send, int send_bytes,
> > @@ -1119,6 +1155,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
> >  
> >  

Re: [Intel-gfx] [PATCH 02/17] drm/i915/icl: add basic support for the ICL clocks

[James Ausmus]

On Thu, Feb 22, 2018 at 12:55:04AM -0300, Paulo Zanoni wrote:
> This commit introduces the definitions for the ICL clocks and adds the
> basic functions to the shared DPLL framework. It adds code for the
> Enable and Disable sequences for some PLLs, but it does not have the
> code to compute the actual PLL values, which are marked as TODO
> comments and should be introduced as separate commits.
> 
> v2:
>  - Rebase around dpll_lock changes.
> v3:
>  - The spec now says what the timeouts should be.
>  - Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze
>the machine.
>  - Checkpatch found a white space problem.
>  - Small adjustments before upstreaming.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c   |  22 +++
>  drivers/gpu/drm/i915/intel_ddi.c  | 102 ++-
>  drivers/gpu/drm/i915/intel_display.c  |  14 ++
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 311 
> +-
>  drivers/gpu/drm/i915/intel_dpll_mgr.h |  41 +
>  drivers/gpu/drm/i915/intel_drv.h  |   6 +
>  6 files changed, 491 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 05b41045b8f9..7ccb5ef212a1 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3180,6 +3180,28 @@ static int i915_shared_dplls_info(struct seq_file *m, 
> void *unused)
>   seq_printf(m, " fp0: 0x%08x\n", pll->state.hw_state.fp0);
>   seq_printf(m, " fp1: 0x%08x\n", pll->state.hw_state.fp1);
>   seq_printf(m, " wrpll:   0x%08x\n", pll->state.hw_state.wrpll);
> + seq_printf(m, " cfgcr0:  0x%08x\n", pll->state.hw_state.cfgcr0);
> + seq_printf(m, " cfgcr1:  0x%08x\n", pll->state.hw_state.cfgcr1);
> + seq_printf(m, " mg_refclkin_ctl:0x%08x\n",
> +pll->state.hw_state.mg_refclkin_ctl);
> + seq_printf(m, " mg_clktop2_coreclkctl1: 0x%08x\n",
> +pll->state.hw_state.mg_clktop2_coreclkctl1);
> + seq_printf(m, " mg_clktop2_hsclkctl:0x%08x\n",
> +pll->state.hw_state.mg_clktop2_hsclkctl);
> + seq_printf(m, " mg_pll_div0:  0x%08x\n",
> +pll->state.hw_state.mg_pll_div0);
> + seq_printf(m, " mg_pll_div1:  0x%08x\n",
> +pll->state.hw_state.mg_pll_div1);
> + seq_printf(m, " mg_pll_lf:0x%08x\n",
> +pll->state.hw_state.mg_pll_lf);
> + seq_printf(m, " mg_pll_frac_lock: 0x%08x\n",
> +pll->state.hw_state.mg_pll_frac_lock);
> + seq_printf(m, " mg_pll_ssc:   0x%08x\n",
> +pll->state.hw_state.mg_pll_ssc);
> + seq_printf(m, " mg_pll_bias:  0x%08x\n",
> +pll->state.hw_state.mg_pll_bias);
> + seq_printf(m, " mg_pll_tdc_coldst_bias: 0x%08x\n",
> +pll->state.hw_state.mg_pll_tdc_coldst_bias);
>   }
>   drm_modeset_unlock_all(dev);
>  
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8ca376aca8bd..81383e3dc91f 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -893,6 +893,23 @@ static uint32_t hsw_pll_to_ddi_pll_sel(const struct 
> intel_shared_dpll *pll)
>   }
>  }
>  
> +static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder,
> +const struct intel_shared_dpll *pll)
> +{
> + switch (pll->id) {
> + default:
> + MISSING_CASE(pll->id);
> + case DPLL_ID_ICL_DPLL0:
> + case DPLL_ID_ICL_DPLL1:
> + return DDI_CLK_SEL_NONE;
> + case DPLL_ID_ICL_MGPLL1:
> + case DPLL_ID_ICL_MGPLL2:
> + case DPLL_ID_ICL_MGPLL3:
> + case DPLL_ID_ICL_MGPLL4:
> + return DDI_CLK_SEL_MG;
> + }
> +}
> +
>  /* Starting with Haswell, different DDI ports can work in FDI mode for
>   * connection to the PCH-located connectors. For this, it is necessary to 
> train
>   * both the DDI port and PCH receiver for the desired DDI buffer settings.
> @@ -2114,6 +2131,75 @@ uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
>   return DDI_BUF_TRANS_SELECT(level);
>  }
>  
> +void icl_map_plls_to_ports(struct drm_crtc *crtc,
> +struct intel_crtc_state *crtc_state,
> +struct drm_atomic_state *old_state)
> +{
> + struct intel_shared_dpll *pll = crtc_state->shared_dpll;
> + struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> + struct drm_connector_state *conn_state;
> + struct drm_connector *conn;
> + int i;
> +
> + if (!IS_ICELAKE(dev_priv))
> + return;
> +
> + for_each_new_connector_in_state(old_state, conn, conn_state, i) {
> + struct 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array
URL   : https://patchwork.freedesktop.org/series/39071/
State : success

== Summary ==

 Known issues:

Test gem_eio:
Subgroup in-flight:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Subgroup in-flight-suspend:
pass   -> SKIP   (shard-snb) fdo#103375
Test kms_cursor_legacy:
Subgroup 2x-long-flip-vs-cursor-atomic:
pass   -> FAIL   (shard-hsw) fdo#104873
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup 2x-flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-indfb-fliptrack:
pass   -> FAIL   (shard-apl) fdo#103167
Subgroup fbc-1p-offscren-pri-indfb-draw-mmap-gtt:
skip   -> PASS   (shard-snb) fdo#101623
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-hsw) fdo#103925
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3426 pass:1803 dwarn:1   dfail:0   fail:8   skip:1612 
time:11706s
shard-hswtotal:3460 pass:1766 dwarn:1   dfail:0   fail:2   skip:1690 
time:11840s
shard-snbtotal:3460 pass:1358 dwarn:1   dfail:0   fail:1   skip:2100 
time:6562s
Blacklisted hosts:
shard-kbltotal:3388 pass:1901 dwarn:1   dfail:0   fail:7   skip:1478 
time:9168s

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Improve PSR activation timing

[Chris Wilson]

Quoting Andy Lutomirski (2018-02-24 00:07:23)
> On Tue, Feb 13, 2018 at 11:26 PM, Rodrigo Vivi  wrote:
> > From: Andy Lutomirski 
> >
> > +
> > +   dev_priv->psr.activate_timer.expires = jiffies - 1;
> 
> That can't possibly be okay.

As an initialisation value, set to the previous jiffie? You can set it
to the current jiffie, but then you have the issue of not noticing the
update to the current jiffie.

So how is this any more incorrect?
-Chris
___
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: Improve PSR activation timing

[Chris Wilson]

Quoting Rodrigo Vivi (2018-02-28 00:14:08)
> From: Andy Lutomirski 
> 
> The current PSR code has a two call sites that each schedule delayed
> work to activate PSR.  As far as I can tell, each call site intends
> to keep PSR inactive for the given amount of time and then allow it
> to be activated.
> 
> The call sites are:
> 
>  - intel_psr_enable(), which explicitly states in a comment that
>it's trying to keep PSR off a short time after the dispay is
>initialized as a workaround.
> 
>  - intel_psr_flush().  There isn't an explcit explanation, but the
>intent is presumably to keep PSR off until the display has been
>idle for 100ms.
> 
> The current code doesn't actually accomplish either of these goals.
> Rather than keeping PSR inactive for the given amount of time, it
> will schedule PSR for activation after the given time, with the
> earliest target time in such a request winning.
> 
> In other words, if intel_psr_enable() is immediately followed by
> intel_psr_flush(), then PSR will be activated after 100ms even if
> intel_psr_enable() wanted a longer delay.  And, if the screen is
> being constantly updated so that intel_psr_flush() is called once
> per frame at 60Hz, PSR will still be activated once every 100ms.
> 
> Rewrite the code so that it does what was intended.  This adds
> a new function intel_psr_schedule(), which will enable PSR after
> the requested time but no sooner.
> 
> v3: (by Rodrigo): Rebased on top of recent drm-tip without any
> modification from the original.
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Andy Lutomirski 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  9 +++--
>  drivers/gpu/drm/i915/i915_drv.h |  4 ++-
>  drivers/gpu/drm/i915/intel_psr.c| 69 
> -
>  3 files changed, 71 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 33fbf3965309..1ac942d1742e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2572,8 +2572,13 @@ static int i915_edp_psr_status(struct seq_file *m, 
> void *data)
> seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
> seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
>dev_priv->psr.busy_frontbuffer_bits);
> -   seq_printf(m, "Re-enable work scheduled: %s\n",
> -  yesno(work_busy(_priv->psr.work.work)));
> +
> +   if (timer_pending(_priv->psr.activate_timer))
> +   seq_printf(m, "Activate scheduled: yes, in %ldms\n",
> +  (long)(dev_priv->psr.earliest_activate - jiffies) *

msecs_from_jiffies

> +  1000 / HZ);
> +   else
> +   seq_printf(m, "Re-enable scheduled: no\n");
>  
> if (HAS_DDI(dev_priv)) {
> if (dev_priv->psr.psr2_support)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7bbec5546d12..6e6cf2ce3749 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -764,7 +764,9 @@ struct i915_psr {
> bool sink_support;
> struct intel_dp *enabled;
> bool active;
> -   struct delayed_work work;
> +   struct timer_list activate_timer;
> +   struct work_struct activate_work;
> +   unsigned long earliest_activate;

Incorporated into struct timer_list, so this is redundant.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/cnl: Add WaRsDisableCoarsePowerGating

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Add WaRsDisableCoarsePowerGating
URL   : https://patchwork.freedesktop.org/series/38807/
State : warning

== Summary ==

 Possible new issues:

Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-left-edge:
pass   -> DMESG-WARN (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup 2x-flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-mmap-gtt:
skip   -> PASS   (shard-snb) fdo#101623
Subgroup fbc-1p-primscrn-cur-indfb-onoff:
pass   -> FAIL   (shard-apl) fdo#103167
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-hsw) fdo#103925
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3388 pass:1775 dwarn:1   dfail:0   fail:8   skip:1602 
time:11873s
shard-hswtotal:3460 pass:1768 dwarn:1   dfail:0   fail:0   skip:1690 
time:12204s
shard-snbtotal:3460 pass:1358 dwarn:2   dfail:0   fail:1   skip:2099 
time:6570s
Blacklisted hosts:
shard-kbltotal:3388 pass:1901 dwarn:1   dfail:0   fail:8   skip:1477 
time:9243s

== Logs ==

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

[Intel-gfx] [PATCH 2/3] drm/i915/psr: Kill scheduled work for Core platforms.

[Rodrigo Vivi]

It is a fact that scheduled work is now improved.

But it is also a fact that on core platforms that shouldn't
be needed. We only need to actually wait on VLV/CHV.

The immediate enabling is actually not an issue for the
HW perspective for core platforms that have HW tracking.
HW will wait few identical idle frames before transitioning
to actual psr active anyways.

Note that this patch also remove the delayed activation
on HSW and BDW introduced by commit 'd0ac896a477d
("drm/i915: Delay first PSR activation.")'. This was
introduced to fix a blank screen on VLV/CHV and also
masked some frozen screens on other core platforms.
Probably the same that we are now properly hunting and fixing.

Furthermore, if we stop using delayed activation on core
platforms we will be able, on following up patches,
to use available workarounds to make HW tracking properly
exit PSR instead of the big nuke of disabling psr and
re-enable on exit and activate respectively.
At least on few reliable cases.

v2:(DK): Remove unnecessary WARN_ONs and make some other
 VLV | CHV more readable.

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 22 +++---
 drivers/gpu/drm/i915/intel_psr.c| 28 ++--
 2 files changed, 29 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1ac942d1742e..fb106b4a3eaf 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2573,19 +2573,14 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
   dev_priv->psr.busy_frontbuffer_bits);
 
-   if (timer_pending(_priv->psr.activate_timer))
-   seq_printf(m, "Activate scheduled: yes, in %ldms\n",
-  (long)(dev_priv->psr.earliest_activate - jiffies) *
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   if (timer_pending(_priv->psr.activate_timer))
+   seq_printf(m, "Activate scheduled: yes, in %ldms\n",
+  (long)(dev_priv->psr.earliest_activate - 
jiffies) *
   1000 / HZ);
-   else
-   seq_printf(m, "Re-enable scheduled: no\n");
-
-   if (HAS_DDI(dev_priv)) {
-   if (dev_priv->psr.psr2_support)
-   enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
else
-   enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
-   } else {
+   seq_printf(m, "Re-enable scheduled: no\n");
+
for_each_pipe(dev_priv, pipe) {
enum transcoder cpu_transcoder =
intel_pipe_to_cpu_transcoder(dev_priv, pipe);
@@ -2604,6 +2599,11 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
 
intel_display_power_put(dev_priv, power_domain);
}
+   } else {
+   if (dev_priv->psr.psr2_support)
+   enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
+   else
+   enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
}
 
seq_printf(m, "Main link in standby mode: %s\n",
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c10d5225dc7c..6d413a7bb39f 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -575,6 +575,9 @@ static void intel_psr_schedule(struct drm_i915_private 
*dev_priv,
 {
unsigned long next;
 
+   if (WARN_ON(!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv
+   return;
+
lockdep_assert_held(_priv->psr.lock);
 
/*
@@ -667,9 +670,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
dev_priv->psr.enable_source(intel_dp, crtc_state);
dev_priv->psr.enabled = intel_dp;
 
-   if (INTEL_GEN(dev_priv) >= 9) {
-   intel_psr_activate(intel_dp);
-   } else {
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
/*
 * FIXME: Activation should happen immediately since this
 * function is just called after pipe is fully trained and
@@ -677,10 +678,10 @@ void intel_psr_enable(struct intel_dp *intel_dp,
 * However on some platforms we face issues when first
 * activation follows a modeset so quickly.
 * - On VLV/CHV we get bank screen on first activation
-* - On HSW/BDW we get a recoverable frozen screen until
-*   next exit-activate sequence.
 */
intel_psr_schedule(dev_priv, intel_dp->panel_power_cycle_delay 
* 5);
+   } else {
+   intel_psr_activate(intel_dp);
   

[Intel-gfx] [PATCH 3/3] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Rodrigo Vivi]

WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
the CPU host modify writes may not get updated on the Display
as expected.
WA: Write 0x to CUR_SURFLIVE_A with every CPU
host modify write to trigger PSR exit."

We can also find on spec other cases where they describe
bogus writes to cursor registers to force PSR exit with
HW tracking. And it was confirmed by HW engineers that
this Wa can be safely applied for any frontbuffer activity.

So let's use this more and more here instead of forcibly
disable and re-enable PSR everytime that we have a simple
reliable flush case.

Other commits improve the fbcon/fbdev use a lot, but this
approach is the only when where we can get a fully reliable
console with no slowness or missed frames and PSR still
enabled and active.

v2: - Rebase on drm-tip
- (DK) Add a comment to explain that WA
tells about writing 0 to CUR_SURFLIVE_A but we write to
CUR_SURFLIVE(pipe).

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h  |  3 +++
 drivers/gpu/drm/i915/intel_psr.c | 18 --
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index eea5b2c537d4..592fad4e43ae 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6014,6 +6014,9 @@ enum {
 #define IVB_CURSOR_B_OFFSET 0x71080
 #define IVB_CURSOR_C_OFFSET 0x72080
 
+#define _CUR_SURLIVE   0x700AC
+#define CUR_SURLIVE(pipe)  _CURSOR2(pipe, _CUR_SURLIVE)
+
 /* Display A control */
 #define _DSPACNTR  0x70180
 #define   DISPLAY_PLANE_ENABLE (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 6d413a7bb39f..a65efdec9026 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -1070,8 +1070,22 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
 
/* By definition flush = invalidate + flush */
-   if (frontbuffer_bits)
-   intel_psr_exit(dev_priv);
+   if (frontbuffer_bits) {
+   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
+   intel_psr_exit(dev_priv);
+   } else {
+   /*
+* Display WA #0884: all
+* This documented WA for bxt can be safely applied
+* broadly so we can force HW tracking to exit PSR
+* instead of disabling and re-enabling.
+* Workaround tells us to write 0 to CUR_SURLIVE_A,
+* but it makes more sense write to the current active
+* pipe.
+*/
+   I915_WRITE(CUR_SURLIVE(pipe), 0);
+   }
+   }
 
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) {
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
-- 
2.13.6

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

[Intel-gfx] [PATCH 1/3] drm/i915: Improve PSR activation timing

[Rodrigo Vivi]

From: Andy Lutomirski 

The current PSR code has a two call sites that each schedule delayed
work to activate PSR.  As far as I can tell, each call site intends
to keep PSR inactive for the given amount of time and then allow it
to be activated.

The call sites are:

 - intel_psr_enable(), which explicitly states in a comment that
   it's trying to keep PSR off a short time after the dispay is
   initialized as a workaround.

 - intel_psr_flush().  There isn't an explcit explanation, but the
   intent is presumably to keep PSR off until the display has been
   idle for 100ms.

The current code doesn't actually accomplish either of these goals.
Rather than keeping PSR inactive for the given amount of time, it
will schedule PSR for activation after the given time, with the
earliest target time in such a request winning.

In other words, if intel_psr_enable() is immediately followed by
intel_psr_flush(), then PSR will be activated after 100ms even if
intel_psr_enable() wanted a longer delay.  And, if the screen is
being constantly updated so that intel_psr_flush() is called once
per frame at 60Hz, PSR will still be activated once every 100ms.

Rewrite the code so that it does what was intended.  This adds
a new function intel_psr_schedule(), which will enable PSR after
the requested time but no sooner.

v3: (by Rodrigo): Rebased on top of recent drm-tip without any
modification from the original.

Cc: Dhinakaran Pandiyan 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  9 +++--
 drivers/gpu/drm/i915/i915_drv.h |  4 ++-
 drivers/gpu/drm/i915/intel_psr.c| 69 -
 3 files changed, 71 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 33fbf3965309..1ac942d1742e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2572,8 +2572,13 @@ static int i915_edp_psr_status(struct seq_file *m, void 
*data)
seq_printf(m, "Active: %s\n", yesno(dev_priv->psr.active));
seq_printf(m, "Busy frontbuffer bits: 0x%03x\n",
   dev_priv->psr.busy_frontbuffer_bits);
-   seq_printf(m, "Re-enable work scheduled: %s\n",
-  yesno(work_busy(_priv->psr.work.work)));
+
+   if (timer_pending(_priv->psr.activate_timer))
+   seq_printf(m, "Activate scheduled: yes, in %ldms\n",
+  (long)(dev_priv->psr.earliest_activate - jiffies) *
+  1000 / HZ);
+   else
+   seq_printf(m, "Re-enable scheduled: no\n");
 
if (HAS_DDI(dev_priv)) {
if (dev_priv->psr.psr2_support)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7bbec5546d12..6e6cf2ce3749 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -764,7 +764,9 @@ struct i915_psr {
bool sink_support;
struct intel_dp *enabled;
bool active;
-   struct delayed_work work;
+   struct timer_list activate_timer;
+   struct work_struct activate_work;
+   unsigned long earliest_activate;
unsigned busy_frontbuffer_bits;
bool psr2_support;
bool aux_frame_sync;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 05770790a4e9..c10d5225dc7c 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -570,6 +570,30 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
dev_priv->psr.active = true;
 }
 
+static void intel_psr_schedule(struct drm_i915_private *dev_priv,
+  unsigned long min_wait_ms)
+{
+   unsigned long next;
+
+   lockdep_assert_held(_priv->psr.lock);
+
+   /*
+* We update next_enable *and* call mod_timer() because it's
+* possible that intel_psr_work() has already been called and is
+* waiting for psr.lock.  If that's the case, we don't want it
+* to immediately enable PSR.
+*
+* We also need to make sure that PSR is never activated earlier
+* than requested to avoid breaking intel_psr_enable()'s workaround
+* for pre-gen9 hardware.
+*/
+   next = jiffies + msecs_to_jiffies(min_wait_ms);
+   if (time_after(next, dev_priv->psr.earliest_activate)) {
+   dev_priv->psr.earliest_activate = next;
+   mod_timer(_priv->psr.activate_timer, next);
+   }
+}
+
 static void hsw_psr_enable_source(struct intel_dp *intel_dp,
  const struct intel_crtc_state *crtc_state)
 {
@@ -656,8 +680,7 @@ void intel_psr_enable(struct intel_dp *intel_dp,
 * - On HSW/BDW we get a recoverable frozen screen until
 *   next exit-activate sequence.
 

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/2] drm/i915/psr2: Fix max resolution supported.

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/psr2: Fix max resolution 
supported.
URL   : https://patchwork.freedesktop.org/series/39068/
State : failure

== Summary ==

 Possible new issues:

Test perf_pmu:
Subgroup busy-check-all-vcs0:
pass   -> FAIL   (shard-snb)

 Known issues:

Test gem_eio:
Subgroup in-flight-contexts:
pass   -> INCOMPLETE (shard-apl) fdo#104945
Test kms_flip:
Subgroup 2x-dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup 2x-flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup plain-flip-fb-recreate:
fail   -> PASS   (shard-hsw) fdo#100368
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-indfb-draw-mmap-gtt:
skip   -> PASS   (shard-snb) fdo#101623
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-hsw) fdo#103925
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047

shard-apltotal:3388 pass:1776 dwarn:1   dfail:0   fail:7   skip:1602 
time:11830s
shard-hswtotal:3460 pass:1767 dwarn:1   dfail:0   fail:1   skip:1690 
time:11759s
shard-snbtotal:3460 pass:1358 dwarn:1   dfail:0   fail:2   skip:2099 
time:6627s
Blacklisted hosts:
shard-kbltotal:3388 pass:1900 dwarn:1   dfail:0   fail:8   skip:1478 
time:9176s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Add WaRsDisableCoarsePowerGating

[Rodrigo Vivi]

On Mon, Feb 26, 2018 at 05:25:12PM -0800, Radhakrishna Sripada wrote:
> On Thu, Feb 22, 2018 at 12:05:35PM -0800, Rodrigo Vivi wrote:
> > Old Wa added now forever on CNL all steppings.
> > 
> > With CPU P states enabled along with RC6, dispatcher
> > hangs can happen.
> > 
> > Cc: Rafael Antognolli 
> > Signed-off-by: Rodrigo Vivi 
> Reviewed-by: Radhakrishna Sripada 

merged, thanks

> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 5 +++--
> >  drivers/gpu/drm/i915/intel_guc.c | 2 +-
> >  drivers/gpu/drm/i915/intel_pm.c  | 2 +-
> >  3 files changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 82a106b1bdbc..7bbec5546d12 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2788,9 +2788,10 @@ intel_info(const struct drm_i915_private *dev_priv)
> >  /* Early gen2 have a totally busted CS tlb and require pinned batches. */
> >  #define HAS_BROKEN_CS_TLB(dev_priv)(IS_I830(dev_priv) || 
> > IS_I845G(dev_priv))
> >  
> > -/* WaRsDisableCoarsePowerGating:skl,bxt */
> > +/* WaRsDisableCoarsePowerGating:skl,cnl */
> >  #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
> > -   (IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> > +   (IS_CANNONLAKE(dev_priv) || \
> > +IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
> >  
> >  /*
> >   * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> > interrupts
> > diff --git a/drivers/gpu/drm/i915/intel_guc.c 
> > b/drivers/gpu/drm/i915/intel_guc.c
> > index 21140ccd7a97..e6512cccef75 100644
> > --- a/drivers/gpu/drm/i915/intel_guc.c
> > +++ b/drivers/gpu/drm/i915/intel_guc.c
> > @@ -370,7 +370,7 @@ int intel_guc_sample_forcewake(struct intel_guc *guc)
> > u32 action[2];
> >  
> > action[0] = INTEL_GUC_ACTION_SAMPLE_FORCEWAKE;
> > -   /* WaRsDisableCoarsePowerGating:skl,bxt */
> > +   /* WaRsDisableCoarsePowerGating:skl,cnl */
> > if (!HAS_RC6(dev_priv) || NEEDS_WaRsDisableCoarsePowerGating(dev_priv))
> > action[1] = 0;
> > else
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 731b3808a62e..c5e495dfa387 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -6695,7 +6695,7 @@ static void gen9_enable_rc6(struct drm_i915_private 
> > *dev_priv)
> >  
> > /*
> >  * 3b: Enable Coarse Power Gating only when RC6 is enabled.
> > -* WaRsDisableCoarsePowerGating:skl,bxt - Render/Media PG need to be 
> > disabled with RC6.
> > +* WaRsDisableCoarsePowerGating:skl,cnl - Render/Media PG need to be 
> > disabled with RC6.
> >  */
> > if (NEEDS_WaRsDisableCoarsePowerGating(dev_priv))
> > I915_WRITE(GEN9_PG_ENABLE, 0);
> > -- 
> > 2.13.6
> > 
> > ___
> > 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] [PATCH v2 2/2] drm/i915/psr: Don't avoid PSR when PSR2 conditions are not met.

[Rodrigo Vivi]

On Tue, Feb 27, 2018 at 02:47:26PM -0800, Pandiyan, Dhinakaran wrote:
> 
> On Tue, 2018-02-27 at 13:29 -0800, Rodrigo Vivi wrote:
> > We can still use PSR1 when PSR2 conditions are not met.
> > 
> > So, let's split the check in a way that we make sure has_psr
> > gets set independently of PSR2 criteria.
> > 
> > v2: Duh! Handle proper return to avoid breaking PSR2.
> > v3: (DK):
> > - better name for psr2 conditions check function
> > - Don't remove FIXME block and psr2.support check.
> > - Add a debug message to show us what PSR or PSR2 is
> >   getting enabled now we have ways to enabled PSR on
> >   PSR2 panels.
> > - s/PSR2 disabled/PSR2 not enabled
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Rodrigo Vivi 
> 
> Reviewed-by: Dhinakaran Pandiyan 

merged, thanks.

> 
> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 64 
> > +++-
> >  1 file changed, 37 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 2f685beac21b..05770790a4e9 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -446,6 +446,41 @@ static void hsw_psr_activate(struct intel_dp *intel_dp)
> > hsw_activate_psr1(intel_dp);
> >  }
> >  
> > +static bool intel_psr2_config_valid(struct intel_dp *intel_dp,
> > +   struct intel_crtc_state *crtc_state)
> > +{
> > +   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > +   const struct drm_display_mode *adjusted_mode =
> > +   _state->base.adjusted_mode;
> > +
> > +   /*
> > +* FIXME psr2_support is messed up. It's both computed
> > +* dynamically during PSR enable, and extracted from sink
> > +* caps during eDP detection.
> > +*/
> > +   if (!dev_priv->psr.psr2_support)
> > +   return false;
> > +
> > +   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> > +   if (adjusted_mode->crtc_hdisplay > 3640 ||
> > +   adjusted_mode->crtc_vdisplay > 2304) {
> > +   DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> > +   return false;
> > +   }
> > +
> > +   /*
> > +* FIXME:enable psr2 only for y-cordinate psr2 panels
> > +* After gtc implementation , remove this restriction.
> > +*/
> > +   if (!dev_priv->psr.y_cord_support) {
> > +   DRM_DEBUG_KMS("PSR2 not enabled, panel does not support Y 
> > coordinate\n");
> > +   return false;
> > +   }
> > +
> > +   return true;
> > +}
> > +
> >  void intel_psr_compute_config(struct intel_dp *intel_dp,
> >   struct intel_crtc_state *crtc_state)
> >  {
> > @@ -513,34 +548,9 @@ void intel_psr_compute_config(struct intel_dp 
> > *intel_dp,
> > return;
> > }
> >  
> > -   /*
> > -* FIXME psr2_support is messed up. It's both computed
> > -* dynamically during PSR enable, and extracted from sink
> > -* caps during eDP detection.
> > -*/
> > -   if (!dev_priv->psr.psr2_support) {
> > -   crtc_state->has_psr = true;
> > -   return;
> > -   }
> > -
> > -   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> > -   if (adjusted_mode->crtc_hdisplay > 3640 ||
> > -   adjusted_mode->crtc_vdisplay > 2304) {
> > -   DRM_DEBUG_KMS("PSR2 disabled, panel resolution too big\n");
> > -   return;
> > -   }
> > -
> > -   /*
> > -* FIXME:enable psr2 only for y-cordinate psr2 panels
> > -* After gtc implementation , remove this restriction.
> > -*/
> > -   if (!dev_priv->psr.y_cord_support) {
> > -   DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y 
> > coordinate\n");
> > -   return;
> > -   }
> > -
> > crtc_state->has_psr = true;
> > -   crtc_state->has_psr2 = true;
> > +   crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
> > +   DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
> >  }
> >  
> >  static void intel_psr_activate(struct intel_dp *intel_dp)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

[Pandiyan, Dhinakaran]

On Tue, 2018-02-27 at 23:34 +0200, Ville Syrjälä wrote:
> On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza wrote:
> > When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> > self, so lets use the mutex register that is available in gen9+ to
> > avoid concurrent access by hardware and driver.
> > Older gen handling will be done separated.
> > 
> > Reference: 
> > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
> > Page 198 - AUX programming sequence
> > 
> > Reviewed-by: Dhinakaran Pandiyan 
> > Reviewed-by: Rodrigo Vivi 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjälä 
> > Signed-off-by: José Roberto de Souza 
> > ---
> > 
> > Changelog:
> > v2
> > - removed the PSR dependency, now getting lock all the times when available
> > - renamed functions to avoid nested calls
> > - moved register bits right after the DP_AUX_CH_MUTEX()
> > - removed 'drm/i915: keep AUX powered while PSR is enabled' Dhinakaran 
> > Pandiyan will sent a better and final version
> > v3
> > - rebased on top of Ville's AUX series
> > - moved port registers to above DP_AUX_CH_MUTEX()
> > - using intel_wait_for_register() instead of the internal version
> > v4
> > - removed virtual function to get mutex register address
> > - enabling the mutex back only on aux channel init
> > - added the aux channel name to the timeout debug message
> > v5
> > - renamed DP_AUX_CH_MUTEX() parameter to aux_ch
> > - renamed goto label when intel_dp_aux_ch_trylock() fails
> > 
> >  drivers/gpu/drm/i915/i915_reg.h |  9 
> >  drivers/gpu/drm/i915/intel_dp.c | 47 
> > +
> >  2 files changed, 56 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index eea5b2c537d4..bce2e6dad4c4 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5385,6 +5385,15 @@ enum {
> >  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
> >  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
> >  
> > +#define _DPA_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6402C)
> > +#define _DPB_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6412C)
> > +#define _DPC_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6422C)
> > +#define _DPD_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6432C)
> > +#define _DPF_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6452C)
> > +#define DP_AUX_CH_MUTEX(aux_ch)_MMIO_PORT(aux_ch, _DPA_AUX_CH_MUTEX, 
> > _DPB_AUX_CH_MUTEX)
> > +#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
> > +#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
> > +
> >  /*
> >   * Computing GMCH M and N values for the Display Port link
> >   *
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 2a3b3ae4e3da..7f4bf77227cd 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1081,6 +1081,42 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
> > intel_dp *intel_dp,
> > aux_clock_divider);
> >  }
> >  
> > +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(intel_dig_port->base.base.dev);
> > +
> > +   if (INTEL_GEN(dev_priv) < 9)
> > +   return true;
> > +
> > +   /* Spec says that mutex is acquired when status bit is read as unset,
> > +* here waiting for 2msec(+-4 aux transactions) before give up.
> > +*/
> > +   if (intel_wait_for_register(dev_priv, DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> > +   DP_AUX_CH_MUTEX_STATUS, 0, 2)) {
> > +   DRM_DEBUG_KMS("aux channel %c locked for 2msec, timing out\n",
> > + aux_ch_name(intel_dp->aux_ch));
> > +   return false;
> > +   }
> > +
> > +   return true;
> > +}
> > +
> > +static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv =
> > +   to_i915(intel_dig_port->base.base.dev);
> > +
> > +   if (INTEL_GEN(dev_priv) < 9)
> > +   return;
> > +
> > +   /* set the status bit releases the mutex + keeping mutex enabled */
> > +   I915_WRITE(DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> > +  DP_AUX_CH_MUTEX_ENABLE | DP_AUX_CH_MUTEX_STATUS);
> > +}
> > +
> >  static int
> >  intel_dp_aux_ch(struct intel_dp *intel_dp,
> > const uint8_t *send, int send_bytes,
> > @@ -1119,6 +1155,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
> >  
> > intel_dp_check_edp(intel_dp);
> >  
> > +   if 

Re: [Intel-gfx] [PATCH 3/5] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

[Rodrigo Vivi]

On Sat, Feb 24, 2018 at 12:24:35AM +, Pandiyan, Dhinakaran wrote:
> On Tue, 2018-02-13 at 15:26 -0800, Rodrigo Vivi wrote:
> > WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR,
> > the CPU host modify writes may not get updated on the Display
> > as expected.
> > WA: Write 0x to CUR_SURFLIVE_A with every CPU
> > host modify write to trigger PSR exit."
> > 
> > We can also find on spec other cases where they describe
> > bogus writes to cursor registers to force PSR exit with
> > HW tracking. And it was confirmed by HW engineers that
> > this Wa can be safely applied for any frontbuffer activity.
> > 
> 
> So the idea is to do a dummy MMIO write to trigger PSR exit.
> 
> > So let's use this more and more here instead of forcibly
> > disable and re-enable PSR everytime that we have a simple
> > reliable flush case.
> > 
> > Other commits improve the fbcon/fbdev use a lot, but this
> > approach is the only when where we can get a fully reliable
> > console with no slowness or missed frames and PSR still
> > enabled and active.
> > 
> > Cc: Dhinakaran Pandiyan 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  |  3 +++
> >  drivers/gpu/drm/i915/intel_psr.c | 15 +--
> >  2 files changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index f6afa5e5e7c1..ac09d17cd835 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6007,6 +6007,9 @@ enum {
> >  #define IVB_CURSOR_B_OFFSET 0x71080
> >  #define IVB_CURSOR_C_OFFSET 0x72080
> >  
> > +#define _CUR_SURLIVE   0x700AC
> > +#define CUR_SURLIVE(pipe)  _CURSOR2(pipe, _CUR_SURLIVE)
> 
> Register address is correct.
> This is a *status* register that provides current surface base address.
> We aren't reading this register anywhere, so writing to it should be
> fine.
> 
> > +
> >  /* Display A control */
> >  #define _DSPACNTR  0x70180
> >  #define   DISPLAY_PLANE_ENABLE (1<<31)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 13409c6301e8..49554036ffb8 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -946,8 +946,19 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
> > dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
> >  
> > /* By definition flush = invalidate + flush */
> > -   if (frontbuffer_bits)
> > -   intel_psr_exit(dev_priv);
> > +   if (frontbuffer_bits) {
> > +   if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > +   intel_psr_exit(dev_priv);
> > +   } else {
> > +   /*
> > +* Display WA #0884: all
> > +* This documented WA for bxt can be safely applied
> > +* broadly so we can force HW tracking to exit PSR
> > +* instead of disabling and re-enabling.
> > +*/
> > +   I915_WRITE(CUR_SURLIVE(pipe), 0);
> 
> The workaround asks 0 to be written to CUR_SURFLIVE_A. But I think
> writing to the active pipe register makes sense.Can you add that to the
> comment since the patch deviates from the workaround?

comment added..

> 
> 
> > +   }
> > +   }
> >  
> > if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) {
> > if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> 
> 
> There is a psr_activate that follows, you should remove that too. HW
> should be able to activate PSR by itself.

I cannot do that. If invalidation came from invalidate the flush
needs to be able to activate it back.

Also it is protected by 
if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)

So it won't be called in vain...

> 
> 
> ___
> 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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array

[Patchwork]

== Series Details ==

Series: drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array
URL   : https://patchwork.freedesktop.org/series/39071/
State : success

== Summary ==

Series 39071v1 drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array
https://patchwork.freedesktop.org/api/1.0/series/39071/revisions/1/mbox/

 Known issues:

Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> INCOMPLETE (fi-pnv-d510) fdo#101600

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:415s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:485s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:477s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:485s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:462s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:454s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:394s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:406s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:445s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:454s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:495s
fi-pnv-d510  total:146  pass:113  dwarn:0   dfail:0   fail:0   skip:32 
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:422s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:464s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:425s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:387s

af8578c6d4389dd9a51ddccc43b8ce4986e27131 drm-tip: 2018y-02m-27d-20h-28m-22s UTC 
integration manifest
5955d6f612b4 drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Add WaRsDisableCoarsePowerGating

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Add WaRsDisableCoarsePowerGating
URL   : https://patchwork.freedesktop.org/series/38807/
State : success

== Summary ==

Series 38807v1 drm/i915/cnl: Add WaRsDisableCoarsePowerGating
https://patchwork.freedesktop.org/api/1.0/series/38807/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
notrun -> INCOMPLETE (fi-bxt-dsi) fdo#103927
pass   -> INCOMPLETE (fi-skl-6260u) fdo#104108
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-ilk-650) fdo#104008 +1

fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:420s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:370s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:481s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:246  pass:219  dwarn:0   dfail:0   fail:0   skip:26 
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:478s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:248  dwarn:0   dfail:0   fail:1   skip:39  
time:458s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:568s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:583s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:419s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:284s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:389s
fi-ilk-650   total:288  pass:227  dwarn:0   dfail:0   fail:1   skip:60  
time:405s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:468s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:411s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:491s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:490s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:246  pass:229  dwarn:0   dfail:0   fail:0   skip:16 
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:503s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:433s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:387s

af8578c6d4389dd9a51ddccc43b8ce4986e27131 drm-tip: 2018y-02m-27d-20h-28m-22s UTC 
integration manifest
6693e22b5b6d drm/i915/cnl: Add WaRsDisableCoarsePowerGating

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/psr: Don't avoid PSR when PSR2 conditions are not met.

[Pandiyan, Dhinakaran]

On Tue, 2018-02-27 at 13:29 -0800, Rodrigo Vivi wrote:
> We can still use PSR1 when PSR2 conditions are not met.
> 
> So, let's split the check in a way that we make sure has_psr
> gets set independently of PSR2 criteria.
> 
> v2: Duh! Handle proper return to avoid breaking PSR2.
> v3: (DK):
>   - better name for psr2 conditions check function
>   - Don't remove FIXME block and psr2.support check.
>   - Add a debug message to show us what PSR or PSR2 is
> getting enabled now we have ways to enabled PSR on
> PSR2 panels.
>   - s/PSR2 disabled/PSR2 not enabled
> 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 

Reviewed-by: Dhinakaran Pandiyan 

> ---
>  drivers/gpu/drm/i915/intel_psr.c | 64 
> +++-
>  1 file changed, 37 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2f685beac21b..05770790a4e9 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -446,6 +446,41 @@ static void hsw_psr_activate(struct intel_dp *intel_dp)
>   hsw_activate_psr1(intel_dp);
>  }
>  
> +static bool intel_psr2_config_valid(struct intel_dp *intel_dp,
> + struct intel_crtc_state *crtc_state)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> + const struct drm_display_mode *adjusted_mode =
> + _state->base.adjusted_mode;
> +
> + /*
> +  * FIXME psr2_support is messed up. It's both computed
> +  * dynamically during PSR enable, and extracted from sink
> +  * caps during eDP detection.
> +  */
> + if (!dev_priv->psr.psr2_support)
> + return false;
> +
> + /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> + if (adjusted_mode->crtc_hdisplay > 3640 ||
> + adjusted_mode->crtc_vdisplay > 2304) {
> + DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
> + return false;
> + }
> +
> + /*
> +  * FIXME:enable psr2 only for y-cordinate psr2 panels
> +  * After gtc implementation , remove this restriction.
> +  */
> + if (!dev_priv->psr.y_cord_support) {
> + DRM_DEBUG_KMS("PSR2 not enabled, panel does not support Y 
> coordinate\n");
> + return false;
> + }
> +
> + return true;
> +}
> +
>  void intel_psr_compute_config(struct intel_dp *intel_dp,
> struct intel_crtc_state *crtc_state)
>  {
> @@ -513,34 +548,9 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>   return;
>   }
>  
> - /*
> -  * FIXME psr2_support is messed up. It's both computed
> -  * dynamically during PSR enable, and extracted from sink
> -  * caps during eDP detection.
> -  */
> - if (!dev_priv->psr.psr2_support) {
> - crtc_state->has_psr = true;
> - return;
> - }
> -
> - /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
> - if (adjusted_mode->crtc_hdisplay > 3640 ||
> - adjusted_mode->crtc_vdisplay > 2304) {
> - DRM_DEBUG_KMS("PSR2 disabled, panel resolution too big\n");
> - return;
> - }
> -
> - /*
> -  * FIXME:enable psr2 only for y-cordinate psr2 panels
> -  * After gtc implementation , remove this restriction.
> -  */
> - if (!dev_priv->psr.y_cord_support) {
> - DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y 
> coordinate\n");
> - return;
> - }
> -
>   crtc_state->has_psr = true;
> - crtc_state->has_psr2 = true;
> + crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
> + DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
>  }
>  
>  static void intel_psr_activate(struct intel_dp *intel_dp)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/psr2: Fix max resolution supported.

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915/psr2: Fix max resolution 
supported.
URL   : https://patchwork.freedesktop.org/series/39068/
State : success

== Summary ==

Series 39068v1 series starting with [v2,1/2] drm/i915/psr2: Fix max resolution 
supported.
https://patchwork.freedesktop.org/api/1.0/series/39068/revisions/1/mbox/

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713 +1

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:487s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:476s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:479s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:465s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:401s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:564s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:409s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:421s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:447s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:497s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:584s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:422s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:515s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:430s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s

af8578c6d4389dd9a51ddccc43b8ce4986e27131 drm-tip: 2018y-02m-27d-20h-28m-22s UTC 
integration manifest
ab5084fb60ff drm/i915/psr: Don't avoid PSR when PSR2 conditions are not met.
01eb17cdf8d6 drm/i915/psr2: Fix max resolution supported.

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915/dp: Add HBR3 rate (8.1 Gbps) to default rates array

[Manasi Navare]

default_rates[] array is a superset of all the link rates supported
by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate
to the set of link rates supported by sink. This patch adds this rate
to default_rates[] array that gets used to populate the sink_rates[]
array limited by max rate obtained from DP_MAX_LINK_RATE DPCD register.

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2a3b3ae..f0766fb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -103,7 +103,7 @@ static const int skl_rates[] = { 162000, 216000, 27,
 static const int cnl_rates[] = { 162000, 216000, 27,
 324000, 432000, 54,
 648000, 81 };
-static const int default_rates[] = { 162000, 27, 54 };
+static const int default_rates[] = { 162000, 27, 54, 81 };
 
 /**
  * intel_dp_is_edp - is the given port attached to an eDP panel (either CPU or 
PCH)
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 01/17] drm/i915/icl: add definitions for the ICL PLL registers

[James Ausmus]

On Thu, Feb 22, 2018 at 12:55:03AM -0300, Paulo Zanoni wrote:
> There's a lot of code for the PLL enabling, so let's first only
> introduce the register definitions in order to make patch reviewing a
> little easier.
> 
> v2: Coding style (Jani).
> v3: Preparation for upstreaming.
> 
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 149 
> 
>  1 file changed, 149 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1412abcb27d4..f62335c4a748 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8783,6 +8783,12 @@ enum skl_power_gate {
>  #define  PORT_CLK_SEL_NONE   (7<<29)
>  #define  PORT_CLK_SEL_MASK   (7<<29)
>  
> +/* On ICL+ this is the same as PORT_CLK_SEL, but all bits change. */
> +#define DDI_CLK_SEL(port)PORT_CLK_SEL(port)
> +#define  DDI_CLK_SEL_NONE(0x0 << 28)
> +#define  DDI_CLK_SEL_MG  (0x8 << 28)
> +#define  DDI_CLK_SEL_MASK(0xF << 28)
> +
>  /* Transcoder clock selection */
>  #define _TRANS_CLK_SEL_A 0x46140
>  #define _TRANS_CLK_SEL_B 0x46144
> @@ -8913,6 +8919,7 @@ enum skl_power_gate {
>   * CNL Clocks
>   */
>  #define DPCLKA_CFGCR0_MMIO(0x6C200)
> +#define DPCLKA_CFGCR0_ICL_MMIO(0x164280)
>  #define  DPCLKA_CFGCR0_DDI_CLK_OFF(port) (1 << ((port) ==  PORT_F ? 23 : 
> \
> (port)+10))
>  #define  DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port)   ((port) == PORT_F ? 21 
> : \
> @@ -8929,10 +8936,141 @@ enum skl_power_gate {
>  #define  PLL_POWER_STATE (1 << 26)
>  #define CNL_DPLL_ENABLE(pll) _MMIO_PLL(pll, DPLL0_ENABLE, DPLL1_ENABLE)
>  
> +#define _MG_PLL1_ENABLE  0x46030
> +#define _MG_PLL2_ENABLE  0x46034
> +#define _MG_PLL3_ENABLE  0x46038
> +#define _MG_PLL4_ENABLE  0x4603C
> +/* Bits are the same as DPLL0_ENABLE */
> +#define MG_PLL_ENABLE(port)  _MMIO_PORT((port) - PORT_C, _MG_PLL1_ENABLE, \
> +_MG_PLL2_ENABLE)
> +
> +#define _MG_REFCLKIN_CTL_PORT1   0x16892C
> +#define _MG_REFCLKIN_CTL_PORT2   0x16992C
> +#define _MG_REFCLKIN_CTL_PORT3   0x16A92C
> +#define _MG_REFCLKIN_CTL_PORT4   0x16B92C
> +#define   MG_REFCLKIN_CTL_OD_2_MUX(x)((x) << 8)
> +#define MG_REFCLKIN_CTL(port) _MMIO_PORT((port) - PORT_C, \
> +  _MG_REFCLKIN_CTL_PORT1, \
> +  _MG_REFCLKIN_CTL_PORT2)
> +
> +#define _MG_CLKTOP2_CORECLKCTL1_PORT10x1690D8
> +#define _MG_CLKTOP2_CORECLKCTL1_PORT20x16B0D8
> +#define _MG_CLKTOP2_CORECLKCTL1_PORT30x16D0D8
> +#define _MG_CLKTOP2_CORECLKCTL1_PORT40x16F0D8
> +#define   MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO(x)   ((x) << 16)
> +#define   MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO(x)   ((x) << 8)
> +#define MG_CLKTOP2_CORECLKCTL1(port) _MMIO_PORT((port) - PORT_C, \
> + _MG_CLKTOP2_CORECLKCTL1_PORT1, \
> + _MG_CLKTOP2_CORECLKCTL1_PORT2)

BSpec 21736 says this register is unused and pending deletion, but in 20845 it 
also
says to program this register. Art, can you shed any light here?

Hmm, on further study, it looks like the MG_CLKTOP_CORECLKCTL1 group
(21340) names the port instances as MG_CLKTOP2_CORECLKCTL1_PORTx, so it
looks like *that* is the actual register group you want (and the
register bit definitions match as well), but, in that case, the
addresses are wrong - they need to be: 0x1688D8, 0x1698D8, 0x16A8D8, and
0x16B8D8, respectively.

> +
> +#define _MG_CLKTOP2_HSCLKCTL_PORT1   0x1688D4
> +#define _MG_CLKTOP2_HSCLKCTL_PORT2   0x1698D4
> +#define _MG_CLKTOP2_HSCLKCTL_PORT3   0x16A8D4
> +#define _MG_CLKTOP2_HSCLKCTL_PORT4   0x16B8D4
> +#define   MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL(x)   ((x) << 16)
> +#define   MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL(x) ((x) << 14)
> +#define   MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO(x) ((x) << 12)
> +#define   MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO(x) ((x) << 8)
> +#define MG_CLKTOP2_HSCLKCTL(port) _MMIO_PORT((port) - PORT_C, \
> +  _MG_CLKTOP2_HSCLKCTL_PORT1, \
> +  _MG_CLKTOP2_HSCLKCTL_PORT2)
> +
> +#define _MG_PLL_DIV0_PORT1   0x168A00
> +#define _MG_PLL_DIV0_PORT2   0x169A00
> +#define _MG_PLL_DIV0_PORT3   0x16AA00
> +#define _MG_PLL_DIV0_PORT4  

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/skl+: Add and enable DP AUX CH mutex

[Patchwork]

== Series Details ==

Series: drm/i915/skl+: Add and enable DP AUX CH mutex
URL   : https://patchwork.freedesktop.org/series/39067/
State : warning

== Summary ==

Series 39067v1 drm/i915/skl+: Add and enable DP AUX CH mutex
https://patchwork.freedesktop.org/api/1.0/series/39067/revisions/1/mbox/

 Possible new issues:

Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-edid:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-load-detect:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-ivb-3520m)

 Known issues:

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-cnl-y3) fdo#104951

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:416s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:483s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:476s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:396s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cnl-y3total:288  pass:261  dwarn:1   dfail:0   fail:0   skip:26  
time:567s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:416s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:385s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:406s
fi-ivb-3520m total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:442s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:409s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:493s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:578s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:428s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:517s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:431s
fi-snb-2520m total:3pass:2dwarn:0   dfail:0   fail:0   skip:0  
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s

af8578c6d4389dd9a51ddccc43b8ce4986e27131 drm-tip: 2018y-02m-27d-20h-28m-22s UTC 
integration manifest
128fb513cbdd drm/i915/skl+: Add and enable DP AUX CH mutex

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Repeat the GEM_BUG_ON message in the ftrace log

[Patchwork]

== Series Details ==

Series: drm/i915: Repeat the GEM_BUG_ON message in the ftrace log
URL   : https://patchwork.freedesktop.org/series/39065/
State : failure

== Summary ==

Series 39065v1 drm/i915: Repeat the GEM_BUG_ON message in the ftrace log
https://patchwork.freedesktop.org/api/1.0/series/39065/revisions/1/mbox/

 Possible new issues:

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

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:414s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:371s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:455s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:577s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:418s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:283s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:455s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:486s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:446s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:492s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:583s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:518s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:480s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:405s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:387s

af8578c6d4389dd9a51ddccc43b8ce4986e27131 drm-tip: 2018y-02m-27d-20h-28m-22s UTC 
integration manifest
f68618bc278e drm/i915: Repeat the GEM_BUG_ON message in the ftrace log

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/6] drm/i915/psr: New power domain for AUX IO.

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/6] drm/i915/psr: New power domain for AUX IO.
URL   : https://patchwork.freedesktop.org/series/38892/
State : success

== Summary ==

 Known issues:

Test kms_flip:
Subgroup 2x-plain-flip-fb-recreate-interruptible:
pass   -> FAIL   (shard-hsw) fdo#100368
Subgroup blocking-wf_vblank:
fail   -> PASS   (shard-hsw) fdo#103928
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-hsw) fdo#103925
Test kms_sysfs_edid_timing:
warn   -> PASS   (shard-apl) fdo#100047
Test kms_vblank:
Subgroup pipe-b-accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583
Test perf:
Subgroup buffer-fill:
fail   -> PASS   (shard-apl) fdo#103755
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715

fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715

shard-apltotal:3460 pass:1820 dwarn:1   dfail:0   fail:7   skip:1632 
time:12122s
shard-hswtotal:3460 pass:1765 dwarn:1   dfail:0   fail:3   skip:1690 
time:11758s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6560s
Blacklisted hosts:
shard-kbltotal:3393 pass:1910 dwarn:1   dfail:0   fail:7   skip:1474 
time:9304s

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

[Ville Syrjälä]

On Tue, Feb 27, 2018 at 01:23:59PM -0800, José Roberto de Souza wrote:
> When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
> self, so lets use the mutex register that is available in gen9+ to
> avoid concurrent access by hardware and driver.
> Older gen handling will be done separated.
> 
> Reference: 
> https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
> Page 198 - AUX programming sequence
> 
> Reviewed-by: Dhinakaran Pandiyan 
> Reviewed-by: Rodrigo Vivi 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: José Roberto de Souza 
> ---
> 
> Changelog:
> v2
> - removed the PSR dependency, now getting lock all the times when available
> - renamed functions to avoid nested calls
> - moved register bits right after the DP_AUX_CH_MUTEX()
> - removed 'drm/i915: keep AUX powered while PSR is enabled' Dhinakaran 
> Pandiyan will sent a better and final version
> v3
> - rebased on top of Ville's AUX series
> - moved port registers to above DP_AUX_CH_MUTEX()
> - using intel_wait_for_register() instead of the internal version
> v4
> - removed virtual function to get mutex register address
> - enabling the mutex back only on aux channel init
> - added the aux channel name to the timeout debug message
> v5
> - renamed DP_AUX_CH_MUTEX() parameter to aux_ch
> - renamed goto label when intel_dp_aux_ch_trylock() fails
> 
>  drivers/gpu/drm/i915/i915_reg.h |  9 
>  drivers/gpu/drm/i915/intel_dp.c | 47 
> +
>  2 files changed, 56 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index eea5b2c537d4..bce2e6dad4c4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5385,6 +5385,15 @@ enum {
>  #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
>  #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
>  
> +#define _DPA_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6402C)
> +#define _DPB_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6412C)
> +#define _DPC_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6422C)
> +#define _DPD_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6432C)
> +#define _DPF_AUX_CH_MUTEX(dev_priv->info.display_mmio_offset + 0x6452C)
> +#define DP_AUX_CH_MUTEX(aux_ch)  _MMIO_PORT(aux_ch, _DPA_AUX_CH_MUTEX, 
> _DPB_AUX_CH_MUTEX)
> +#define   DP_AUX_CH_MUTEX_ENABLE (1 << 31)
> +#define   DP_AUX_CH_MUTEX_STATUS (1 << 30)
> +
>  /*
>   * Computing GMCH M and N values for the Display Port link
>   *
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 2a3b3ae4e3da..7f4bf77227cd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1081,6 +1081,42 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
> intel_dp *intel_dp,
>   aux_clock_divider);
>  }
>  
> +static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> +
> + if (INTEL_GEN(dev_priv) < 9)
> + return true;
> +
> + /* Spec says that mutex is acquired when status bit is read as unset,
> +  * here waiting for 2msec(+-4 aux transactions) before give up.
> +  */
> + if (intel_wait_for_register(dev_priv, DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> + DP_AUX_CH_MUTEX_STATUS, 0, 2)) {
> + DRM_DEBUG_KMS("aux channel %c locked for 2msec, timing out\n",
> +   aux_ch_name(intel_dp->aux_ch));
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv =
> + to_i915(intel_dig_port->base.base.dev);
> +
> + if (INTEL_GEN(dev_priv) < 9)
> + return;
> +
> + /* set the status bit releases the mutex + keeping mutex enabled */
> + I915_WRITE(DP_AUX_CH_MUTEX(intel_dp->aux_ch),
> +DP_AUX_CH_MUTEX_ENABLE | DP_AUX_CH_MUTEX_STATUS);
> +}
> +
>  static int
>  intel_dp_aux_ch(struct intel_dp *intel_dp,
>   const uint8_t *send, int send_bytes,
> @@ -1119,6 +1155,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
>  
>   intel_dp_check_edp(intel_dp);
>  
> + if (!intel_dp_aux_ch_trylock(intel_dp)) {
> + ret = -EBUSY;
> + goto out_aux_ch_unlocked;
> + }
> +
>   /* Try to wait for any previous AUX channel activity */
>   for (try = 0; try < 3; try++) {
>

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/cnl: Add WaRsDisableCoarsePowerGating

[Patchwork]

== Series Details ==

Series: drm/i915/cnl: Add WaRsDisableCoarsePowerGating
URL   : https://patchwork.freedesktop.org/series/38807/
State : failure

== Summary ==

Series 38807v1 drm/i915/cnl: Add WaRsDisableCoarsePowerGating
https://patchwork.freedesktop.org/api/1.0/series/38807/revisions/1/mbox/

 Possible new issues:

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-hsw-4770)

 Known issues:

Test debugfs_test:
Subgroup read_all_entries:
incomplete -> PASS   (fi-snb-2520m) fdo#103713
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> FAIL   (fi-cnl-y3) fdo#103167

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:417s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:427s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:374s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:481s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:284s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:478s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:482s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:462s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:557s
fi-cnl-y3total:288  pass:261  dwarn:0   dfail:0   fail:1   skip:26  
time:579s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:412s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:508s
fi-hsw-4770  total:108  pass:99   dwarn:0   dfail:0   fail:0   skip:8  
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:408s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:446s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:488s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:445s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:490s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:585s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:426s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:404s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:434s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:394s

af8578c6d4389dd9a51ddccc43b8ce4986e27131 drm-tip: 2018y-02m-27d-20h-28m-22s UTC 
integration manifest
f9f96e9603b1 drm/i915/cnl: Add WaRsDisableCoarsePowerGating

== Logs ==

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

[Intel-gfx] [PATCH v2 1/2] drm/i915/psr2: Fix max resolution supported.

[Rodrigo Vivi]

According to spec:
"PSR2 is supported for pipe active sizes up to
3640 pixels wide and 2304 lines tall."

BSpec: 7713

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_psr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 1f77633fe809..2f685beac21b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -523,9 +523,9 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
return;
}
 
-   /* PSR2 is restricted to work with panel resolutions upto 3200x2000 */
-   if (adjusted_mode->crtc_hdisplay > 3200 ||
-   adjusted_mode->crtc_vdisplay > 2000) {
+   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
+   if (adjusted_mode->crtc_hdisplay > 3640 ||
+   adjusted_mode->crtc_vdisplay > 2304) {
DRM_DEBUG_KMS("PSR2 disabled, panel resolution too big\n");
return;
}
-- 
2.13.6

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

[Intel-gfx] [PATCH v2 2/2] drm/i915/psr: Don't avoid PSR when PSR2 conditions are not met.

[Rodrigo Vivi]

We can still use PSR1 when PSR2 conditions are not met.

So, let's split the check in a way that we make sure has_psr
gets set independently of PSR2 criteria.

v2: Duh! Handle proper return to avoid breaking PSR2.
v3: (DK):
- better name for psr2 conditions check function
- Don't remove FIXME block and psr2.support check.
- Add a debug message to show us what PSR or PSR2 is
  getting enabled now we have ways to enabled PSR on
  PSR2 panels.
- s/PSR2 disabled/PSR2 not enabled

Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_psr.c | 64 +++-
 1 file changed, 37 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2f685beac21b..05770790a4e9 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -446,6 +446,41 @@ static void hsw_psr_activate(struct intel_dp *intel_dp)
hsw_activate_psr1(intel_dp);
 }
 
+static bool intel_psr2_config_valid(struct intel_dp *intel_dp,
+   struct intel_crtc_state *crtc_state)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+   const struct drm_display_mode *adjusted_mode =
+   _state->base.adjusted_mode;
+
+   /*
+* FIXME psr2_support is messed up. It's both computed
+* dynamically during PSR enable, and extracted from sink
+* caps during eDP detection.
+*/
+   if (!dev_priv->psr.psr2_support)
+   return false;
+
+   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
+   if (adjusted_mode->crtc_hdisplay > 3640 ||
+   adjusted_mode->crtc_vdisplay > 2304) {
+   DRM_DEBUG_KMS("PSR2 not enabled, panel resolution too big\n");
+   return false;
+   }
+
+   /*
+* FIXME:enable psr2 only for y-cordinate psr2 panels
+* After gtc implementation , remove this restriction.
+*/
+   if (!dev_priv->psr.y_cord_support) {
+   DRM_DEBUG_KMS("PSR2 not enabled, panel does not support Y 
coordinate\n");
+   return false;
+   }
+
+   return true;
+}
+
 void intel_psr_compute_config(struct intel_dp *intel_dp,
  struct intel_crtc_state *crtc_state)
 {
@@ -513,34 +548,9 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
return;
}
 
-   /*
-* FIXME psr2_support is messed up. It's both computed
-* dynamically during PSR enable, and extracted from sink
-* caps during eDP detection.
-*/
-   if (!dev_priv->psr.psr2_support) {
-   crtc_state->has_psr = true;
-   return;
-   }
-
-   /* PSR2 is restricted to work with panel resolutions up to 3640x2304 */
-   if (adjusted_mode->crtc_hdisplay > 3640 ||
-   adjusted_mode->crtc_vdisplay > 2304) {
-   DRM_DEBUG_KMS("PSR2 disabled, panel resolution too big\n");
-   return;
-   }
-
-   /*
-* FIXME:enable psr2 only for y-cordinate psr2 panels
-* After gtc implementation , remove this restriction.
-*/
-   if (!dev_priv->psr.y_cord_support) {
-   DRM_DEBUG_KMS("PSR2 disabled, panel does not support Y 
coordinate\n");
-   return;
-   }
-
crtc_state->has_psr = true;
-   crtc_state->has_psr2 = true;
+   crtc_state->has_psr2 = intel_psr2_config_valid(intel_dp, crtc_state);
+   DRM_DEBUG_KMS("Enabling PSR%s\n", crtc_state->has_psr2 ? "2" : "");
 }
 
 static void intel_psr_activate(struct intel_dp *intel_dp)
-- 
2.13.6

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

[Intel-gfx] [PATCH] drm/i915/skl+: Add and enable DP AUX CH mutex

[José Roberto de Souza]

When PSR/PSR2/GTC is enabled hardware can do AUX transactions by it
self, so lets use the mutex register that is available in gen9+ to
avoid concurrent access by hardware and driver.
Older gen handling will be done separated.

Reference: 
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol12-display.pdf
Page 198 - AUX programming sequence

Reviewed-by: Dhinakaran Pandiyan 
Reviewed-by: Rodrigo Vivi 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: José Roberto de Souza 
---

Changelog:
v2
- removed the PSR dependency, now getting lock all the times when available
- renamed functions to avoid nested calls
- moved register bits right after the DP_AUX_CH_MUTEX()
- removed 'drm/i915: keep AUX powered while PSR is enabled' Dhinakaran Pandiyan 
will sent a better and final version
v3
- rebased on top of Ville's AUX series
- moved port registers to above DP_AUX_CH_MUTEX()
- using intel_wait_for_register() instead of the internal version
v4
- removed virtual function to get mutex register address
- enabling the mutex back only on aux channel init
- added the aux channel name to the timeout debug message
v5
- renamed DP_AUX_CH_MUTEX() parameter to aux_ch
- renamed goto label when intel_dp_aux_ch_trylock() fails

 drivers/gpu/drm/i915/i915_reg.h |  9 
 drivers/gpu/drm/i915/intel_dp.c | 47 +
 2 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index eea5b2c537d4..bce2e6dad4c4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5385,6 +5385,15 @@ enum {
 #define   DP_AUX_CH_CTL_FW_SYNC_PULSE_SKL(c) (((c) - 1) << 5)
 #define   DP_AUX_CH_CTL_SYNC_PULSE_SKL(c)   ((c) - 1)
 
+#define _DPA_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6402C)
+#define _DPB_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6412C)
+#define _DPC_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6422C)
+#define _DPD_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6432C)
+#define _DPF_AUX_CH_MUTEX  (dev_priv->info.display_mmio_offset + 0x6452C)
+#define DP_AUX_CH_MUTEX(aux_ch)_MMIO_PORT(aux_ch, _DPA_AUX_CH_MUTEX, 
_DPB_AUX_CH_MUTEX)
+#define   DP_AUX_CH_MUTEX_ENABLE   (1 << 31)
+#define   DP_AUX_CH_MUTEX_STATUS   (1 << 30)
+
 /*
  * Computing GMCH M and N values for the Display Port link
  *
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2a3b3ae4e3da..7f4bf77227cd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1081,6 +1081,42 @@ static uint32_t intel_dp_get_aux_send_ctl(struct 
intel_dp *intel_dp,
aux_clock_divider);
 }
 
+static bool intel_dp_aux_ch_trylock(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv =
+   to_i915(intel_dig_port->base.base.dev);
+
+   if (INTEL_GEN(dev_priv) < 9)
+   return true;
+
+   /* Spec says that mutex is acquired when status bit is read as unset,
+* here waiting for 2msec(+-4 aux transactions) before give up.
+*/
+   if (intel_wait_for_register(dev_priv, DP_AUX_CH_MUTEX(intel_dp->aux_ch),
+   DP_AUX_CH_MUTEX_STATUS, 0, 2)) {
+   DRM_DEBUG_KMS("aux channel %c locked for 2msec, timing out\n",
+ aux_ch_name(intel_dp->aux_ch));
+   return false;
+   }
+
+   return true;
+}
+
+static void intel_dp_aux_ch_unlock(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv =
+   to_i915(intel_dig_port->base.base.dev);
+
+   if (INTEL_GEN(dev_priv) < 9)
+   return;
+
+   /* set the status bit releases the mutex + keeping mutex enabled */
+   I915_WRITE(DP_AUX_CH_MUTEX(intel_dp->aux_ch),
+  DP_AUX_CH_MUTEX_ENABLE | DP_AUX_CH_MUTEX_STATUS);
+}
+
 static int
 intel_dp_aux_ch(struct intel_dp *intel_dp,
const uint8_t *send, int send_bytes,
@@ -1119,6 +1155,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 
intel_dp_check_edp(intel_dp);
 
+   if (!intel_dp_aux_ch_trylock(intel_dp)) {
+   ret = -EBUSY;
+   goto out_aux_ch_unlocked;
+   }
+
/* Try to wait for any previous AUX channel activity */
for (try = 0; try < 3; try++) {
status = I915_READ_NOTRACE(ch_ctl);
@@ -1240,6 +1281,8 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 
ret = recv_bytes;
 out:
+   intel_dp_aux_ch_unlock(intel_dp);
+out_aux_ch_unlocked:

Re: [Intel-gfx] [PATCH 4/4] drm/i915/icl: Interrupt handling

[Paulo Zanoni]

Em Ter, 2018-02-27 às 11:51 -0800, Daniele Ceraolo Spurio escreveu:
> 
> On 20/02/18 07:37, Mika Kuoppala wrote:
> > v2: Rebase.
> > 
> > v3:
> >* Remove DPF, it has been removed from SKL+.
> >* Fix -internal rebase wrt. execlists interrupt handling.
> > 
> > v4: Rebase.
> > 
> > v5:
> >* Updated for POR changes. (Daniele Ceraolo Spurio)
> >* Merged with irq handling fixes by Daniele Ceraolo Spurio:
> >* Simplify the code by using gen8_cs_irq_handler.
> >* Fix interrupt handling for the upstream kernel.
> > 
> > v6:
> >* Remove early bringup debug messages (Tvrtko)
> >* Add NB about arbitrary spin wait timeout (Tvrtko)
> > 
> > v7 (from Paulo):
> >* Don't try to write RO bits to registers.
> >* Don't check for PCH types that don't exist. PCH interrupts are
> > not
> >  here yet.
> > 
> > v9:
> >* squashed in selector and shared register handling (Daniele)
> >* skip writing of irq if data is not valid (Daniele)
> >* use time_after32 (Chris)
> >* use I915_MAX_VCS and I915_MAX_VECS (Daniele)
> >* remove fake pm interrupt handling for later patch (Mika)
> > 
> > v10:
> >* Direct processing of banks. clear banks early (Chris)
> >* remove poll on valid bit, only clear valid bit (Mika)
> >* use raw accessors, better naming (Chris)
> > 
> > v11:
> >* adapt to raw_reg_[read|write]
> >* bring back polling the valid bit (Daniele)
> > 
> > Cc: Tvrtko Ursulin 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Chris Wilson 
> > Cc: Oscar Mateo 
> > Signed-off-by: Tvrtko Ursulin 
> > Signed-off-by: Rodrigo Vivi 
> > Signed-off-by: Daniele Ceraolo Spurio  > com>
> > Signed-off-by: Oscar Mateo 
> > Signed-off-by: Paulo Zanoni 
> > Signed-off-by: Mika Kuoppala 
> > ---
> >   drivers/gpu/drm/i915/i915_irq.c | 229
> > 
> >   drivers/gpu/drm/i915/intel_pm.c |   7 +-
> >   2 files changed, 235 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 17de6cef2a30..a79f47ac742a 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct
> > drm_i915_private *dev_priv)
> > if (READ_ONCE(rps->interrupts_enabled))
> > return;
> >   
> > +   if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> > +   return;
> > +
> > spin_lock_irq(_priv->irq_lock);
> > WARN_ON_ONCE(rps->pm_iir);
> > WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & dev_priv-
> > >pm_rps_events);
> > @@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct
> > drm_i915_private *dev_priv)
> > if (!READ_ONCE(rps->interrupts_enabled))
> > return;
> >   
> > +   if (WARN_ON_ONCE(IS_GEN11(dev_priv)))
> > +   return;
> > +
> > spin_lock_irq(_priv->irq_lock);
> > rps->interrupts_enabled = false;
> >   
> > @@ -2755,6 +2761,150 @@ static void __fini_wedge(struct wedge_me
> > *w)
> >  (W)->i915; 
> > \
> >  __fini_wedge((W)))
> >   
> > +static __always_inline void
> > +gen11_cs_irq_handler(struct intel_engine_cs * const engine, const
> > u32 iir)
> > +{
> > +   gen8_cs_irq_handler(engine, iir, 0);
> > +}
> > +
> > +static void
> > +gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
> > +   const unsigned int bank,
> > +   const unsigned int engine_n,
> > +   const u16 iir)
> > +{
> > +   struct intel_engine_cs ** const engine = i915->engine;
> > +
> > +   switch (bank) {
> > +   case 0:
> > +   switch (engine_n) {
> > +
> > +   case GEN11_RCS0:
> > +   return gen11_cs_irq_handler(engine[RCS],
> > iir);
> > +
> > +   case GEN11_BCS:
> > +   return gen11_cs_irq_handler(engine[BCS],
> > iir);
> > +   }
> > +   case 1:
> > +   switch (engine_n) {
> > +
> > +   case GEN11_VCS(0):
> > +   return
> > gen11_cs_irq_handler(engine[_VCS(0)], iir);
> > +   case GEN11_VCS(1):
> > +   return
> > gen11_cs_irq_handler(engine[_VCS(1)], iir);
> > +   case GEN11_VCS(2):
> > +   return
> > gen11_cs_irq_handler(engine[_VCS(2)], iir);
> > +   case GEN11_VCS(3):
> > +   return
> > gen11_cs_irq_handler(engine[_VCS(3)], iir);
> > +
> > +   case GEN11_VECS(0):
> > +   return
> > gen11_cs_irq_handler(engine[_VECS(0)], iir);
> > +   case GEN11_VECS(1):
> > +   return
> > gen11_cs_irq_handler(engine[_VECS(1)], iir);
> > +   }
> > +   }
> > +}
> > +

[Intel-gfx] [PATCH] drm/i915: Repeat the GEM_BUG_ON message in the ftrace log

[Chris Wilson]

As the ftrace log is overflowing the pstore capture, we lose the gasps
from dmesg which includes the GEM_BUG_ON function:line and condition that
failed. Vital information for tracking down the bug, so append it to the
frace log as well.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index e920dab7f1b8..d9f0709973d1 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -29,7 +29,10 @@
 
 #ifdef CONFIG_DRM_I915_DEBUG_GEM
 #define GEM_BUG_ON(condition) do { if (unlikely((condition))) {\
-   printk(KERN_ERR "GEM_BUG_ON(%s)\n", __stringify(condition)); \
+   pr_err("%s:%d GEM_BUG_ON(%s)\n", \
+  __func__, __LINE__, __stringify(condition)); \
+   GEM_TRACE("%s:%d GEM_BUG_ON(%s)\n", \
+ __func__, __LINE__, __stringify(condition)); \
BUG(); \
} \
} while(0)
-- 
2.16.2

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

Re: [Intel-gfx] [RFC] drm/i915/dp: move link rate arrays where they're used

[Manasi Navare]

On Tue, Feb 27, 2018 at 08:52:49PM +0200, Jani Nikula wrote:
> On Tue, 27 Feb 2018, "Pandiyan, Dhinakaran"  
> wrote:
> > On Tue, 2018-02-27 at 12:59 +0200, Jani Nikula wrote:
> >> Localize link rate arrays by moving them to the functions where they're
> >> used.
> >
> > I feel this array expresses platform capability concisely and it's easy
> > to quickly check what rates a platform supports when the array is at the
> > top. But,that's probably just me.
> 
> I could argue both ways myself, hence RFC. :)
> 
> BR,
> Jani.
>

I prefer the localized array of these per platform rates since its better if
this information is abstracted from the user and user only sees an array 
source_rates[].
Per platform rates will still be part of separate arrays for debug purposes and 
to check
them within code, but since the rest of the driver only uses source_rates, 
sink_rates,
common_rates arrays, having these per platform arrays local to the function 
make more sense.

Regards
Manasi

> 
> -- 
> 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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] kernel/panic: Repeat the line and caller information at the end of the OOPS

[Chris Wilson]

Quoting Lofstedt, Marta (2018-02-27 11:12:52)
> OK cool I'll look out for it landing, CI_DRM_3838 or CI_DRM_3839 I guess.

Bah, wrong path. This is only called to handle WARN() and we need the
extra information in BUG(). In fact, the information we need is in a raw
printk and not given to WARN, so we'll have to try a different tack.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Exit PSR before do a aux transaction in gen < 9

[Pandiyan, Dhinakaran]

On Fri, 2018-02-23 at 18:03 -0800, José Roberto de Souza wrote:
> As gen < 9 hardware don't have the aux ch mutex, we need to exit PSR
> and wait until it is back to inactive state before do any aux ch
> transaction.
> 

I wonder if we need this for CHV/VLV since the HW does not send PSR aux
transactions on it's own.

> Signed-off-by: José Roberto de Souza 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  |  8 +++-
>  drivers/gpu/drm/i915/intel_drv.h |  9 +
>  drivers/gpu/drm/i915/intel_psr.c | 42 
> ++--
>  3 files changed, 52 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 7be2fec51651..dacdd98bbb2e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1088,8 +1088,14 @@ static bool intel_dp_aux_ch_trylock(struct intel_dp 
> *intel_dp)
>   to_i915(intel_dig_port->base.base.dev);
>   i915_reg_t ch_mutex;
>  
> - if (!intel_dp->aux_ch_mutex_reg)
> + if (!intel_dp->aux_ch_mutex_reg) {
> + /* As gen < 9 hardware don't have the aux ch mutex, we need to
> +  * exit PSR and wait until it is back to inactive state before
> +  * do any aux ch transaction
> +  */
> + intel_psr_exit(intel_dp, true);
>   return true;
> + }
>  
>   ch_mutex = intel_dp->aux_ch_mutex_reg(intel_dp);
>   I915_WRITE(ch_mutex, DP_AUX_CH_MUTEX_ENABLE);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 267cc6c5a89f..7adcd5955d1b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1881,6 +1881,15 @@ void intel_psr_single_frame_update(struct 
> drm_i915_private *dev_priv,
>  unsigned frontbuffer_bits);
>  void intel_psr_compute_config(struct intel_dp *intel_dp,
> struct intel_crtc_state *crtc_state);
> +/**
> + * Exit PSR in the given DisplayPort.
> + * @intel_dp: DisplayPort which PSR should be exit if running
> + * @wait_exit: if true it will wait until PSR have changed to inactive state,
> + * otherwise there is not wait.
> + *
> + * It will also schedule a work to try to active PSR again.
> + */
> +void intel_psr_exit(struct intel_dp *intel_dp, bool wait_exit);
>  
>  /* intel_runtime_pm.c */
>  int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index e8c32c3afb0e..0b889c85e8da 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -56,6 +56,8 @@
>  #include "intel_drv.h"
>  #include "i915_drv.h"
>  
> +#define PSR_ACTIVE_DELAY_MSEC 100
> +
>  static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -486,6 +488,16 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp,
>   }
>  }
>  
> +static void intel_psr_active_schedule(struct i915_psr *psr,
> +   unsigned int msec_delay)
> +{
> + if (psr->active || psr->busy_frontbuffer_bits)
> + return;
> +
> + if (!work_busy(>work.work))
> + schedule_delayed_work(>work, msecs_to_jiffies(msec_delay));

This change will conflict with
https://patchwork.freedesktop.org/series/38199/


> +}
> +
>  /**
>   * intel_psr_enable - Enable PSR
>   * @intel_dp: Intel DP
> @@ -534,8 +546,9 @@ void intel_psr_enable(struct intel_dp *intel_dp,
>* - On HSW/BDW we get a recoverable frozen screen until
>*   next exit-activate sequence.
>*/
> - schedule_delayed_work(_priv->psr.work,
> -   
> msecs_to_jiffies(intel_dp->panel_power_cycle_delay * 5));
> + intel_psr_active_schedule(_priv->psr,
> +   intel_dp->panel_power_cycle_delay
> +   * 5);
>   }
>  
>  unlock:
> @@ -886,10 +899,7 @@ void intel_psr_flush(struct drm_i915_private *dev_priv,
>   if (frontbuffer_bits)
>   dev_priv->psr.exit(dev_priv->psr.enabled, false);
>  
> - if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
> - if (!work_busy(_priv->psr.work.work))
> - schedule_delayed_work(_priv->psr.work,
> -   msecs_to_jiffies(100));
> + intel_psr_active_schedule(_priv->psr, PSR_ACTIVE_DELAY_MSEC);
>   mutex_unlock(_priv->psr.lock);
>  }
>  
> @@ -955,3 +965,23 @@ void intel_psr_init(struct drm_i915_private *dev_priv)
>   dev_priv->psr.exit = hsw_psr_exit;
>   }
>  }
> +
> +void intel_psr_exit(struct intel_dp *intel_dp, bool wait_exit)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + 

Re: [Intel-gfx] [PATCH] drm/i915/psr: Check for power state control capability.

[Rodrigo Vivi]

On Tue, Feb 27, 2018 at 09:55:56AM -0800, Nathan Ciobanu wrote:
> On Mon, Feb 26, 2018 at 07:27:23PM -0800, Dhinakaran Pandiyan wrote:
> > eDP spec says - "If PSR/PSR2 is supported, the SET_POWER_CAPABLE bit in the
> > EDP_GENERAL_CAPABILITY_1 register (DPCD Address 00701h, bit d7) must be set
> > to 1."
> > 
> > Reject PSR on panels without this cap bit set as such panels cannot be
> > controlled via SET_POWER & SET_DP_PWR_VOLTAGE register and the DP source
> > needs to be able to do that for PSR.
> > 
> > Thanks to Nathan for debugging this.
> > 
> > Panel cap checks like this can be done just once, let's fix this
> > when PSR dpcd init movement lands.
> > 
> > Cc: Nathan D Ciobanu 
> > Cc: Rodrigo Vivi 
> > Signed-off-by: Dhinakaran Pandiyan 
>  Tested-by: Nathan Ciobanu 

Reviewed-by: Rodrigo Vivi 

merging right now. Thanks for the patch, debugs and testing.

> > ---
> >  drivers/gpu/drm/i915/intel_psr.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 89f41d28c44a..e0701b7f87f7 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -405,6 +405,11 @@ void intel_psr_compute_config(struct intel_dp 
> > *intel_dp,
> > return;
> > }
> >  
> > +   if (!(intel_dp->edp_dpcd[1] & DP_EDP_SET_POWER_CAP)) {
> > +   DRM_DEBUG_KMS("PSR condition failed: panel lacks power state 
> > control\n");
> > +   return;
> > +   }
> > +
> > /*
> >  * FIXME psr2_support is messed up. It's both computed
> >  * dynamically during PSR enable, and extracted from sink
> > -- 
> > 2.14.1
> > 
> > ___
> > 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] igt/gem_fd_exhaustion: Actually test error handling on fd exhaustion

[Patchwork]

== Series Details ==

Series: series starting with [1/2] igt/gem_fd_exhaustion: Actually test error 
handling on fd exhaustion
URL   : https://patchwork.freedesktop.org/series/39051/
State : failure

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-b-ts-continuation-modeset-rpm:
fail   -> PASS   (shard-hsw)
Subgroup pipe-b-ts-continuation-suspend:
skip   -> PASS   (shard-snb)
Subgroup pipe-c-ts-continuation-dpms-rpm:
fail   -> PASS   (shard-hsw)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> FAIL   (shard-hsw)
Subgroup cursor-dpms:
pass   -> FAIL   (shard-hsw)
Subgroup debugfs-read:
pass   -> FAIL   (shard-hsw)
Subgroup dpms-mode-unset-non-lpsp:
fail   -> PASS   (shard-hsw)
Subgroup gem-evict-pwrite:
fail   -> PASS   (shard-hsw)
Subgroup gem-execbuf:
fail   -> PASS   (shard-hsw)
Subgroup gem-execbuf-stress-extra-wait:
fail   -> PASS   (shard-hsw)
Subgroup gem-idle:
fail   -> PASS   (shard-hsw)
Subgroup gem-mmap-cpu:
fail   -> PASS   (shard-hsw)
Subgroup i2c:
fail   -> PASS   (shard-hsw)
Subgroup modeset-lpsp:
fail   -> SKIP   (shard-hsw)
Subgroup modeset-lpsp-stress:
fail   -> SKIP   (shard-hsw)
Subgroup pm-caching:
fail   -> PASS   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_flip:
Subgroup flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887
Test kms_rotation_crc:
Subgroup sprite-rotation-180:
fail   -> PASS   (shard-snb) fdo#103925
Test kms_vblank:
Subgroup pipe-b-accuracy-idle:
pass   -> FAIL   (shard-hsw) fdo#102583
Test perf:
Subgroup buffer-fill:
pass   -> FAIL   (shard-apl) fdo#103755
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Test perf_pmu:
Subgroup rc6-runtime-pm-long:
skip   -> PASS   (shard-hsw) fdo#105010
Test pm_lpsp:
Subgroup screens-disabled:
fail   -> PASS   (shard-hsw) fdo#104941

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715
fdo#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010
fdo#104941 https://bugs.freedesktop.org/show_bug.cgi?id=104941

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:8   skip:1632 
time:12240s
shard-hswtotal:3460 pass:1735 dwarn:1   dfail:0   fail:34  skip:1689 
time:11625s
shard-snbtotal:3460 pass:1359 dwarn:1   dfail:0   fail:1   skip:2099 
time:6641s
Blacklisted hosts:
shard-kbltotal:3460 pass:1941 dwarn:5   dfail:0   fail:7   skip:1507 
time:9647s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Try to make display info less nuts

[Patchwork]

== Series Details ==

Series: drm: Try to make display info less nuts
URL   : https://patchwork.freedesktop.org/series/39046/
State : failure

== Summary ==

 Possible new issues:

Test kms_vblank:
Subgroup pipe-b-ts-continuation-suspend:
skip   -> PASS   (shard-snb)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> FAIL   (shard-hsw)
Subgroup debugfs-read:
pass   -> FAIL   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-128x128-right-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185
Test kms_flip:
Subgroup flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715

fdo#104945 https://bugs.freedesktop.org/show_bug.cgi?id=104945
fdo#105185 https://bugs.freedesktop.org/show_bug.cgi?id=105185
fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:7   skip:1632 
time:12264s
shard-hswtotal:3460 pass:1725 dwarn:1   dfail:0   fail:45  skip:1688 
time:11974s
shard-snbtotal:3460 pass:1357 dwarn:2   dfail:0   fail:2   skip:2099 
time:6660s
Blacklisted hosts:
shard-kbltotal:3442 pass:1924 dwarn:1   dfail:0   fail:7   skip:1509 
time:9276s

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/15] drm/i915/guc: Tidy guc_log_control

[Patchwork]

== Series Details ==

Series: series starting with [01/15] drm/i915/guc: Tidy guc_log_control
URL   : https://patchwork.freedesktop.org/series/39043/
State : failure

== Summary ==

 Possible new issues:

Test drv_missed_irq:
pass   -> SKIP   (shard-apl)
Test drv_selftest:
Subgroup live_guc:
pass   -> DMESG-WARN (shard-apl)
Test perf:
Subgroup gen8-unprivileged-single-ctx-counters:
pass   -> FAIL   (shard-apl)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> FAIL   (shard-hsw)
Subgroup cursor-dpms:
pass   -> FAIL   (shard-hsw)
Subgroup debugfs-read:
pass   -> FAIL   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_chv_cursor_fail:
Subgroup pipe-b-256x256-left-edge:
pass   -> DMESG-WARN (shard-snb) fdo#105185
Test kms_cursor_legacy:
Subgroup flip-vs-cursor-varying-size:
pass   -> FAIL   (shard-hsw) fdo#102670
Test kms_flip:
Subgroup flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887
Subgroup plain-flip-fb-recreate:
pass   -> FAIL   (shard-hsw) fdo#100368 +1
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

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

shard-apltotal:3404 pass:1778 dwarn:2   dfail:0   fail:14  skip:1609 
time:12335s
shard-hswtotal:3460 pass:1720 dwarn:1   dfail:0   fail:50  skip:1688 
time:11952s
shard-snbtotal:3362 pass:1316 dwarn:2   dfail:0   fail:2   skip:2042 
time:6424s
Blacklisted hosts:
shard-kbltotal:3400 pass:1889 dwarn:2   dfail:1   fail:15  skip:1488 
time:8621s

== Logs ==

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

Re: [Intel-gfx] [CI 1/6] drm/i915/psr: New power domain for AUX IO.

[Rodrigo Vivi]

On Tue, Feb 27, 2018 at 10:24:27AM -0800, Nathan Ciobanu wrote:
> On Fri, Feb 23, 2018 at 02:15:15PM -0800, Dhinakaran Pandiyan wrote:
> > From: "Dhinakaran Pandiyan" 
> > 
> > PSR on CNL requires AUX IO wells to be kept on and the existing AUX domain
> > for AUX-A enables DC_OFF well too. This is not required, so add a new
> > AUX_IO_A domain for AUX-A to allow DC states to remain enabled. Other AUX
> > channels re-use the existing AUX domains.
> > 
> > v4: Reword comment (Rodrigo and Ville)
> > Rename _get and _put functions to include aux_io substring(Rodrigo)
> > Remove unnecessary diff that got included.
> > v3: Extract aux domain selection into a function (Ville)
> > v2: Add AUX IO domain only for AUX-A
> > Rebased on top of Ville's AUX series.
> > 
> > Cc: Imre Deak 
> > Cc: Rodrigo Vivi 
> > Cc: Ville Syrjälä 
> > Suggested-by: Imre Deak 
> > Signed-off-by: Dhinakaran Pandiyan 
> > Reviewed-by: Rodrigo Vivi 
>  Tested-by: Nathan Ciobanu 

ops. I'm sorry for leaving this out. I end up merging the patches
before seeing this here.

all 6 patches merged on dinq now. Thanks for the patches and reviews.

> > ---
> >  drivers/gpu/drm/i915/intel_display.h|  1 +
> >  drivers/gpu/drm/i915/intel_psr.c| 41 
> > +
> >  drivers/gpu/drm/i915/intel_runtime_pm.c |  3 +++
> >  3 files changed, 45 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.h 
> > b/drivers/gpu/drm/i915/intel_display.h
> > index f5733a2576e7..4e7418b345bc 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -186,6 +186,7 @@ enum intel_display_power_domain {
> > POWER_DOMAIN_AUX_C,
> > POWER_DOMAIN_AUX_D,
> > POWER_DOMAIN_AUX_F,
> > +   POWER_DOMAIN_AUX_IO_A,
> > POWER_DOMAIN_GMBUS,
> > POWER_DOMAIN_MODESET,
> > POWER_DOMAIN_GT_IRQ,
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 2ef374f936b9..04430d4c99c9 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -56,6 +56,43 @@
> >  #include "intel_drv.h"
> >  #include "i915_drv.h"
> >  
> > +static inline enum intel_display_power_domain
> > +psr_aux_domain(struct intel_dp *intel_dp)
> > +{
> > +   /* CNL HW requires corresponding AUX IOs to be powered up for PSR.
> > +* However, for non-A AUX ports the corresponding non-EDP transcoders
> > +* would have already enabled power well 2 and DC_OFF. This means we can
> > +* acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference instead of a
> > +* specific AUX_IO reference without powering up any extra wells.
> > +* Note that PSR is enabled only on Port A even though this function
> > +* returns the correct domain for other ports too.
> > +*/
> > +   return intel_dp->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A :
> > + intel_dp->aux_power_domain;
> > +}
> > +
> > +static void psr_aux_io_power_get(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv = 
> > to_i915(intel_dig_port->base.base.dev);
> > +
> > +   if (INTEL_GEN(dev_priv) < 10)
> > +   return;
> > +
> > +   intel_display_power_get(dev_priv, psr_aux_domain(intel_dp));
> > +}
> > +
> > +static void psr_aux_io_power_put(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > +   struct drm_i915_private *dev_priv = 
> > to_i915(intel_dig_port->base.base.dev);
> > +
> > +   if (INTEL_GEN(dev_priv) < 10)
> > +   return;
> > +
> > +   intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
> > +}
> > +
> >  static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
> >  {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > @@ -459,6 +496,8 @@ static void hsw_psr_enable_source(struct intel_dp 
> > *intel_dp,
> > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > u32 chicken;
> >  
> > +   psr_aux_io_power_get(intel_dp);
> > +
> > if (dev_priv->psr.psr2_support) {
> > chicken = PSR2_VSC_ENABLE_PROG_HEADER;
> > if (dev_priv->psr.y_cord_support)
> > @@ -617,6 +656,8 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
> > else
> > WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> > }
> > +
> > +   psr_aux_io_power_put(intel_dp);
> >  }
> >  
> >  /**
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index b7924feb9f27..53ea564f971e 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: move link rate arrays where they're used

[Patchwork]

== Series Details ==

Series: drm/i915/dp: move link rate arrays where they're used
URL   : https://patchwork.freedesktop.org/series/39032/
State : failure

== Summary ==

 Possible new issues:

Test kms_draw_crc:
Subgroup draw-method-rgb565-blt-untiled:
pass   -> SKIP   (shard-snb)
Test kms_vblank:
Subgroup pipe-b-ts-continuation-suspend:
skip   -> PASS   (shard-snb)
Test pm_rpm:
Subgroup cursor-dpms:
pass   -> FAIL   (shard-hsw)

 Known issues:

Test gem_eio:
Subgroup in-flight:
incomplete -> PASS   (shard-apl) fdo#104945
Test kms_flip:
Subgroup flip-vs-expired-vblank:
fail   -> PASS   (shard-hsw) fdo#102887
Test kms_sysfs_edid_timing:
pass   -> WARN   (shard-apl) fdo#100047
Test perf:
Subgroup enable-disable:
fail   -> PASS   (shard-apl) fdo#103715
Subgroup polling:
pass   -> FAIL   (shard-hsw) fdo#102252

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

shard-apltotal:3460 pass:1819 dwarn:1   dfail:0   fail:7   skip:1632 
time:12342s
shard-hswtotal:3460 pass:1725 dwarn:1   dfail:0   fail:45  skip:1688 
time:11991s
shard-snbtotal:3460 pass:1357 dwarn:1   dfail:0   fail:2   skip:2100 
time:6656s
Blacklisted hosts:
shard-kbltotal:3460 pass:1943 dwarn:1   dfail:0   fail:7   skip:1509 
time:9620s

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915/icl: Interrupt handling

[Daniele Ceraolo Spurio]

On 20/02/18 07:37, Mika Kuoppala wrote:

v2: Rebase.

v3:
   * Remove DPF, it has been removed from SKL+.
   * Fix -internal rebase wrt. execlists interrupt handling.

v4: Rebase.

v5:
   * Updated for POR changes. (Daniele Ceraolo Spurio)
   * Merged with irq handling fixes by Daniele Ceraolo Spurio:
   * Simplify the code by using gen8_cs_irq_handler.
   * Fix interrupt handling for the upstream kernel.

v6:
   * Remove early bringup debug messages (Tvrtko)
   * Add NB about arbitrary spin wait timeout (Tvrtko)

v7 (from Paulo):
   * Don't try to write RO bits to registers.
   * Don't check for PCH types that don't exist. PCH interrupts are not
 here yet.

v9:
   * squashed in selector and shared register handling (Daniele)
   * skip writing of irq if data is not valid (Daniele)
   * use time_after32 (Chris)
   * use I915_MAX_VCS and I915_MAX_VECS (Daniele)
   * remove fake pm interrupt handling for later patch (Mika)

v10:
   * Direct processing of banks. clear banks early (Chris)
   * remove poll on valid bit, only clear valid bit (Mika)
   * use raw accessors, better naming (Chris)

v11:
   * adapt to raw_reg_[read|write]
   * bring back polling the valid bit (Daniele)

Cc: Tvrtko Ursulin 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Oscar Mateo 
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
Signed-off-by: Paulo Zanoni 
Signed-off-by: Mika Kuoppala 
---
  drivers/gpu/drm/i915/i915_irq.c | 229 
  drivers/gpu/drm/i915/intel_pm.c |   7 +-
  2 files changed, 235 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 17de6cef2a30..a79f47ac742a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -415,6 +415,9 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (READ_ONCE(rps->interrupts_enabled))
return;
  
+	if (WARN_ON_ONCE(IS_GEN11(dev_priv)))

+   return;
+
spin_lock_irq(_priv->irq_lock);
WARN_ON_ONCE(rps->pm_iir);
WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
@@ -431,6 +434,9 @@ void gen6_disable_rps_interrupts(struct drm_i915_private 
*dev_priv)
if (!READ_ONCE(rps->interrupts_enabled))
return;
  
+	if (WARN_ON_ONCE(IS_GEN11(dev_priv)))

+   return;
+
spin_lock_irq(_priv->irq_lock);
rps->interrupts_enabled = false;
  
@@ -2755,6 +2761,150 @@ static void __fini_wedge(struct wedge_me *w)

 (W)->i915;  \
 __fini_wedge((W)))
  
+static __always_inline void

+gen11_cs_irq_handler(struct intel_engine_cs * const engine, const u32 iir)
+{
+   gen8_cs_irq_handler(engine, iir, 0);
+}
+
+static void
+gen11_gt_engine_irq_handler(struct drm_i915_private * const i915,
+   const unsigned int bank,
+   const unsigned int engine_n,
+   const u16 iir)
+{
+   struct intel_engine_cs ** const engine = i915->engine;
+
+   switch (bank) {
+   case 0:
+   switch (engine_n) {
+
+   case GEN11_RCS0:
+   return gen11_cs_irq_handler(engine[RCS], iir);
+
+   case GEN11_BCS:
+   return gen11_cs_irq_handler(engine[BCS], iir);
+   }
+   case 1:
+   switch (engine_n) {
+
+   case GEN11_VCS(0):
+   return gen11_cs_irq_handler(engine[_VCS(0)], iir);
+   case GEN11_VCS(1):
+   return gen11_cs_irq_handler(engine[_VCS(1)], iir);
+   case GEN11_VCS(2):
+   return gen11_cs_irq_handler(engine[_VCS(2)], iir);
+   case GEN11_VCS(3):
+   return gen11_cs_irq_handler(engine[_VCS(3)], iir);
+
+   case GEN11_VECS(0):
+   return gen11_cs_irq_handler(engine[_VECS(0)], iir);
+   case GEN11_VECS(1):
+   return gen11_cs_irq_handler(engine[_VECS(1)], iir);
+   }
+   }
+}
+
+static u32
+gen11_gt_engine_intr(struct drm_i915_private * const i915,
+const unsigned int bank, const unsigned int bit)
+{
+   void __iomem * const regs = i915->regs;
+   u32 timeout_ts;
+   u32 ident;
+
+   raw_reg_write(regs, GEN11_IIR_REG_SELECTOR(bank), BIT(bit));
+
+   /*
+* NB: Specs do not specify how long to spin wait,
+* so we do ~100us as an educated guess.
+*/
+   timeout_ts = 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/6] drm/i915/psr: New power domain for AUX IO.

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/6] drm/i915/psr: New power domain for AUX IO.
URL   : https://patchwork.freedesktop.org/series/38892/
State : success

== Summary ==

Series 38892v1 series starting with [CI,1/6] drm/i915/psr: New power domain for 
AUX IO.
https://patchwork.freedesktop.org/api/1.0/series/38892/revisions/1/mbox/

 Known issues:

Test kms_chamelium:
Subgroup dp-edid-read:
fail   -> PASS   (fi-kbl-7500u) fdo#102505
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
incomplete -> PASS   (fi-snb-2520m) fdo#103713

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

fi-bdw-5557u total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  
time:413s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:474s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:483s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:393s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:559s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:282s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:386s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:408s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:493s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:418s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:504s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:515s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:428s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:390s

f78296fbab2b98b4ccb32ab3a0fae05b47836b15 drm-tip: 2018y-02m-27d-16h-24m-05s UTC 
integration manifest
92801cf8f384 drm/i915/dp: Move comment about hw timeout to the right place.
ee0c3fb15978 drm/i915/dp: Remove redundant sleep after AUX transaction length 
check.
8693a1aeeeb9 drm/i915/psr: Check for the specific AUX_FRAME_SYNC cap bit.
8e5d79ad53b9 drm/i915/psr: Extract PSR DPCD initialization and move it to 
intel_psr.c
e5fcf5bdc1ec drm/i915/frontbuffer: Mark frontbuffer flush and invalidate with 
might_sleep()
7cecfb4fc7e6 drm/i915/psr: New power domain for AUX IO.

== Logs ==

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

Re: [Intel-gfx] [RFC] drm/i915/dp: move link rate arrays where they're used

[Jani Nikula]

On Tue, 27 Feb 2018, "Pandiyan, Dhinakaran"  
wrote:
> On Tue, 2018-02-27 at 12:59 +0200, Jani Nikula wrote:
>> Localize link rate arrays by moving them to the functions where they're
>> used.
>
> I feel this array expresses platform capability concisely and it's easy
> to quickly check what rates a platform supports when the array is at the
> top. But,that's probably just me.

I could argue both ways myself, hence RFC. :)

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] [RFC] drm/i915/dp: move link rate arrays where they're used

[Jani Nikula]

On Tue, 27 Feb 2018, Manasi Navare  wrote:
> On Tue, Feb 27, 2018 at 12:59:11PM +0200, Jani Nikula wrote:
>> Localize link rate arrays by moving them to the functions where they're
>> used. Further clarify the distinction between source and sink
>> capabilities. Split pre and post Haswell arrays, and get rid of the
>> array size arithmetics. Use a direct rate value in the paranoia case of
>> no common rates find.
>> 
>> Cc: Manasi Navare 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 44 
>> +
>>  1 file changed, 27 insertions(+), 17 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 801a21b16004..6fa6583b16bd 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -96,15 +96,6 @@ static const struct dp_link_dpll chv_dpll[] = {
>>  { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
>>  };
>>  
>> -static const int bxt_rates[] = { 162000, 216000, 243000, 27,
>> -  324000, 432000, 54 };
>> -static const int skl_rates[] = { 162000, 216000, 27,
>> -  324000, 432000, 54 };
>> -static const int cnl_rates[] = { 162000, 216000, 27,
>> - 324000, 432000, 54,
>> - 648000, 81 };
>> -static const int default_rates[] = { 162000, 27, 54 };
>> -
>>  /**
>>   * intel_dp_is_edp - is the given port attached to an eDP panel (either CPU 
>> or PCH)
>>   * @intel_dp: DP struct
>> @@ -144,14 +135,17 @@ static void intel_dp_unset_edid(struct intel_dp 
>> *intel_dp);
>>  /* update sink rates from dpcd */
>>  static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
>>  {
>> +static const int dp_rates[] = {
>> +162000, 27, 54
>> +};
>
> Now that the sink rates can be as high as 81, shouldnt dp_rates[] include 
> that rate?
> Since we use this to populate sink_rates, if the max rate from dpcd is 
> 81, currently
> the sink rates will not get populated with that.

This patch is non-functional. Any other changes should be on top.

BR,
Jani.


>
> Manasi
>
>>  int i, max_rate;
>>  
>>  max_rate = 
>> drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>>  
>> -for (i = 0; i < ARRAY_SIZE(default_rates); i++) {
>> -if (default_rates[i] > max_rate)
>> +for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
>> +if (dp_rates[i] > max_rate)
>>  break;
>> -intel_dp->sink_rates[i] = default_rates[i];
>> +intel_dp->sink_rates[i] = dp_rates[i];
>>  }
>>  
>>  intel_dp->num_sink_rates = i;
>> @@ -268,6 +262,22 @@ static int cnl_max_source_rate(struct intel_dp 
>> *intel_dp)
>>  static void
>>  intel_dp_set_source_rates(struct intel_dp *intel_dp)
>>  {
>> +/* The values must be in increasing order */
>> +static const int cnl_rates[] = {
>> +162000, 216000, 27, 324000, 432000, 54, 648000, 81
>> +};
>> +static const int bxt_rates[] = {
>> +162000, 216000, 243000, 27, 324000, 432000, 54
>> +};
>> +static const int skl_rates[] = {
>> +162000, 216000, 27, 324000, 432000, 54
>> +};
>> +static const int hsw_rates[] = {
>> +162000, 27, 54
>> +};
>> +static const int g4x_rates[] = {
>> +162000, 27
>> +};
>>  struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>>  struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
>>  const struct ddi_vbt_port_info *info =
>> @@ -290,11 +300,11 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
>>  size = ARRAY_SIZE(skl_rates);
>>  } else if ((IS_HASWELL(dev_priv) && !IS_HSW_ULX(dev_priv)) ||
>> IS_BROADWELL(dev_priv)) {
>> -source_rates = default_rates;
>> -size = ARRAY_SIZE(default_rates);
>> +source_rates = hsw_rates;
>> +size = ARRAY_SIZE(hsw_rates);
>>  } else {
>> -source_rates = default_rates;
>> -size = ARRAY_SIZE(default_rates) - 1;
>> +source_rates = g4x_rates;
>> +size = ARRAY_SIZE(g4x_rates);
>>  }
>>  
>>  if (max_rate && vbt_max_rate)
>> @@ -356,7 +366,7 @@ static void intel_dp_set_common_rates(struct intel_dp 
>> *intel_dp)
>>  
>>  /* Paranoia, there should always be something in common. */
>>  if (WARN_ON(intel_dp->num_common_rates == 0)) {
>> -intel_dp->common_rates[0] = default_rates[0];
>> +intel_dp->common_rates[0] = 162000;
>>  intel_dp->num_common_rates = 1;
>>  }
>>  }
>> -- 
>> 2.11.0
>> 

-- 
Jani Nikula, Intel Open Source Technology 

Re: [Intel-gfx] [CI 1/6] drm/i915/psr: New power domain for AUX IO.

[Nathan Ciobanu]

On Fri, Feb 23, 2018 at 02:15:15PM -0800, Dhinakaran Pandiyan wrote:
> From: "Dhinakaran Pandiyan" 
> 
> PSR on CNL requires AUX IO wells to be kept on and the existing AUX domain
> for AUX-A enables DC_OFF well too. This is not required, so add a new
> AUX_IO_A domain for AUX-A to allow DC states to remain enabled. Other AUX
> channels re-use the existing AUX domains.
> 
> v4: Reword comment (Rodrigo and Ville)
> Rename _get and _put functions to include aux_io substring(Rodrigo)
> Remove unnecessary diff that got included.
> v3: Extract aux domain selection into a function (Ville)
> v2: Add AUX IO domain only for AUX-A
> Rebased on top of Ville's AUX series.
> 
> Cc: Imre Deak 
> Cc: Rodrigo Vivi 
> Cc: Ville Syrjälä 
> Suggested-by: Imre Deak 
> Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Rodrigo Vivi 
 Tested-by: Nathan Ciobanu 
> ---
>  drivers/gpu/drm/i915/intel_display.h|  1 +
>  drivers/gpu/drm/i915/intel_psr.c| 41 
> +
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  3 +++
>  3 files changed, 45 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.h 
> b/drivers/gpu/drm/i915/intel_display.h
> index f5733a2576e7..4e7418b345bc 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -186,6 +186,7 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_AUX_C,
>   POWER_DOMAIN_AUX_D,
>   POWER_DOMAIN_AUX_F,
> + POWER_DOMAIN_AUX_IO_A,
>   POWER_DOMAIN_GMBUS,
>   POWER_DOMAIN_MODESET,
>   POWER_DOMAIN_GT_IRQ,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2ef374f936b9..04430d4c99c9 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -56,6 +56,43 @@
>  #include "intel_drv.h"
>  #include "i915_drv.h"
>  
> +static inline enum intel_display_power_domain
> +psr_aux_domain(struct intel_dp *intel_dp)
> +{
> + /* CNL HW requires corresponding AUX IOs to be powered up for PSR.
> +  * However, for non-A AUX ports the corresponding non-EDP transcoders
> +  * would have already enabled power well 2 and DC_OFF. This means we can
> +  * acquire a wider POWER_DOMAIN_AUX_{B,C,D,F} reference instead of a
> +  * specific AUX_IO reference without powering up any extra wells.
> +  * Note that PSR is enabled only on Port A even though this function
> +  * returns the correct domain for other ports too.
> +  */
> + return intel_dp->aux_ch == AUX_CH_A ? POWER_DOMAIN_AUX_IO_A :
> +   intel_dp->aux_power_domain;
> +}
> +
> +static void psr_aux_io_power_get(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv = 
> to_i915(intel_dig_port->base.base.dev);
> +
> + if (INTEL_GEN(dev_priv) < 10)
> + return;
> +
> + intel_display_power_get(dev_priv, psr_aux_domain(intel_dp));
> +}
> +
> +static void psr_aux_io_power_put(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv = 
> to_i915(intel_dig_port->base.base.dev);
> +
> + if (INTEL_GEN(dev_priv) < 10)
> + return;
> +
> + intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
> +}
> +
>  static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -459,6 +496,8 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp,
>   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>   u32 chicken;
>  
> + psr_aux_io_power_get(intel_dp);
> +
>   if (dev_priv->psr.psr2_support) {
>   chicken = PSR2_VSC_ENABLE_PROG_HEADER;
>   if (dev_priv->psr.y_cord_support)
> @@ -617,6 +656,8 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
>   else
>   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
>   }
> +
> + psr_aux_io_power_put(intel_dp);
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index b7924feb9f27..53ea564f971e 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -130,6 +130,8 @@ intel_display_power_domain_str(enum 
> intel_display_power_domain domain)
>   return "AUX_D";
>   case POWER_DOMAIN_AUX_F:
>   return "AUX_F";
> + case POWER_DOMAIN_AUX_IO_A:
> + return "AUX_IO_A";
>   case POWER_DOMAIN_GMBUS:
>   return "GMBUS";
>   case POWER_DOMAIN_INIT:
> @@ -1853,6 

Re: [Intel-gfx] [RFC] drm/i915/dp: move link rate arrays where they're used

[Manasi Navare]

On Tue, Feb 27, 2018 at 12:59:11PM +0200, Jani Nikula wrote:
> Localize link rate arrays by moving them to the functions where they're
> used. Further clarify the distinction between source and sink
> capabilities. Split pre and post Haswell arrays, and get rid of the
> array size arithmetics. Use a direct rate value in the paranoia case of
> no common rates find.
> 
> Cc: Manasi Navare 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 44 
> +
>  1 file changed, 27 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 801a21b16004..6fa6583b16bd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -96,15 +96,6 @@ static const struct dp_link_dpll chv_dpll[] = {
>   { .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
>  };
>  
> -static const int bxt_rates[] = { 162000, 216000, 243000, 27,
> -   324000, 432000, 54 };
> -static const int skl_rates[] = { 162000, 216000, 27,
> -   324000, 432000, 54 };
> -static const int cnl_rates[] = { 162000, 216000, 27,
> -  324000, 432000, 54,
> -  648000, 81 };
> -static const int default_rates[] = { 162000, 27, 54 };
> -
>  /**
>   * intel_dp_is_edp - is the given port attached to an eDP panel (either CPU 
> or PCH)
>   * @intel_dp: DP struct
> @@ -144,14 +135,17 @@ static void intel_dp_unset_edid(struct intel_dp 
> *intel_dp);
>  /* update sink rates from dpcd */
>  static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
>  {
> + static const int dp_rates[] = {
> + 162000, 27, 54
> + };

Now that the sink rates can be as high as 81, shouldnt dp_rates[] include 
that rate?
Since we use this to populate sink_rates, if the max rate from dpcd is 81, 
currently
the sink rates will not get populated with that.

Manasi

>   int i, max_rate;
>  
>   max_rate = 
> drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
>  
> - for (i = 0; i < ARRAY_SIZE(default_rates); i++) {
> - if (default_rates[i] > max_rate)
> + for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
> + if (dp_rates[i] > max_rate)
>   break;
> - intel_dp->sink_rates[i] = default_rates[i];
> + intel_dp->sink_rates[i] = dp_rates[i];
>   }
>  
>   intel_dp->num_sink_rates = i;
> @@ -268,6 +262,22 @@ static int cnl_max_source_rate(struct intel_dp *intel_dp)
>  static void
>  intel_dp_set_source_rates(struct intel_dp *intel_dp)
>  {
> + /* The values must be in increasing order */
> + static const int cnl_rates[] = {
> + 162000, 216000, 27, 324000, 432000, 54, 648000, 81
> + };
> + static const int bxt_rates[] = {
> + 162000, 216000, 243000, 27, 324000, 432000, 54
> + };
> + static const int skl_rates[] = {
> + 162000, 216000, 27, 324000, 432000, 54
> + };
> + static const int hsw_rates[] = {
> + 162000, 27, 54
> + };
> + static const int g4x_rates[] = {
> + 162000, 27
> + };
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
>   const struct ddi_vbt_port_info *info =
> @@ -290,11 +300,11 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
>   size = ARRAY_SIZE(skl_rates);
>   } else if ((IS_HASWELL(dev_priv) && !IS_HSW_ULX(dev_priv)) ||
>  IS_BROADWELL(dev_priv)) {
> - source_rates = default_rates;
> - size = ARRAY_SIZE(default_rates);
> + source_rates = hsw_rates;
> + size = ARRAY_SIZE(hsw_rates);
>   } else {
> - source_rates = default_rates;
> - size = ARRAY_SIZE(default_rates) - 1;
> + source_rates = g4x_rates;
> + size = ARRAY_SIZE(g4x_rates);
>   }
>  
>   if (max_rate && vbt_max_rate)
> @@ -356,7 +366,7 @@ static void intel_dp_set_common_rates(struct intel_dp 
> *intel_dp)
>  
>   /* Paranoia, there should always be something in common. */
>   if (WARN_ON(intel_dp->num_common_rates == 0)) {
> - intel_dp->common_rates[0] = default_rates[0];
> + intel_dp->common_rates[0] = 162000;
>   intel_dp->num_common_rates = 1;
>   }
>  }
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] drm/i915/dp: move link rate arrays where they're used

[Pandiyan, Dhinakaran]

On Tue, 2018-02-27 at 12:59 +0200, Jani Nikula wrote:
> Localize link rate arrays by moving them to the functions where they're
> used.

I feel this array expresses platform capability concisely and it's easy
to quickly check what rates a platform supports when the array is at the
top. But,that's probably just me.

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

Re: [Intel-gfx] [PATCH] drm/i915/psr: Check for power state control capability.

[Nathan Ciobanu]

On Mon, Feb 26, 2018 at 07:27:23PM -0800, Dhinakaran Pandiyan wrote:
> eDP spec says - "If PSR/PSR2 is supported, the SET_POWER_CAPABLE bit in the
> EDP_GENERAL_CAPABILITY_1 register (DPCD Address 00701h, bit d7) must be set
> to 1."
> 
> Reject PSR on panels without this cap bit set as such panels cannot be
> controlled via SET_POWER & SET_DP_PWR_VOLTAGE register and the DP source
> needs to be able to do that for PSR.
> 
> Thanks to Nathan for debugging this.
> 
> Panel cap checks like this can be done just once, let's fix this
> when PSR dpcd init movement lands.
> 
> Cc: Nathan D Ciobanu 
> Cc: Rodrigo Vivi 
> Signed-off-by: Dhinakaran Pandiyan 
 Tested-by: Nathan Ciobanu 
> ---
>  drivers/gpu/drm/i915/intel_psr.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 89f41d28c44a..e0701b7f87f7 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -405,6 +405,11 @@ void intel_psr_compute_config(struct intel_dp *intel_dp,
>   return;
>   }
>  
> + if (!(intel_dp->edp_dpcd[1] & DP_EDP_SET_POWER_CAP)) {
> + DRM_DEBUG_KMS("PSR condition failed: panel lacks power state 
> control\n");
> + return;
> + }
> +
>   /*
>* FIXME psr2_support is messed up. It's both computed
>* dynamically during PSR enable, and extracted from sink
> -- 
> 2.14.1
> 
> ___
> 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] [PATCH] drm: i915: Fix audio issue on BXT

[Runyan, Arthur J]

Ok, please update the workaround page to show all the impacted projects
https://gfxspecs.intel.com/Predator/Home/Index/21829


> -Original Message-
> From: Mullah, Abid A
> Sent: Tuesday, 27 February, 2018 8:52 AM
> To: Runyan, Arthur J ; Pandiyan, Dhinakaran
> ; Singh, Gaurav K
> ; Neelagandan, Harigaran
> 
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
> Nikula, Jani 
> Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> 
> Yes. It will be needed for BXT also.
> 
> -Original Message-
> From: Runyan, Arthur J
> Sent: Tuesday, February 27, 2018 8:49 AM
> To: Pandiyan, Dhinakaran ; Singh, Gaurav
> K ; Mullah, Abid A ;
> Neelagandan, Harigaran 
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
> Nikula, Jani 
> Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> 
> Abid or Hari, please check.  There was a workaround to set
> AUD_CHICKENBIT_REG bit 15 (Codec Wake overwrite to DACFEUNIT) on SKL
> and KBL.  Does it apply to BXT also?
> 
> > -Original Message-
> > From: Pandiyan, Dhinakaran
> > Sent: Monday, 26 February, 2018 6:04 PM
> > To: Runyan, Arthur J ; Singh, Gaurav K
> > 
> > Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo
> > ; Nikula, Jani 
> > Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> >
> >
> > > -Original Message-
> > > From: Runyan, Arthur J
> > > Sent: Tuesday, January 9, 2018 11:55 AM
> > > To: Pandiyan, Dhinakaran ; Singh,
> > Gaurav K
> > > 
> > > Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo
> > > 
> > > Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> > >
> > > Sorry, I've been out.  I'm checking on this.
> >
> >
> > Hi Art,
> >
> > Is AUD_CHICKENBIT_REG:15 needed for BXT to fix code enumeration
> issues?
> >
> > -DK
> >
> > >
> > > -Original Message-
> > > From: Pandiyan, Dhinakaran
> > > Sent: Thursday, 4 January, 2018 2:00 PM
> > > To: Singh, Gaurav K 
> > > Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo
> > > ; subransu.s.pru...@intel.com; Runyan,
> > > Arthur J
> > 
> > > Subject: Re: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> > >
> > > +Art
> > >
> > > On Thu, 2018-01-04 at 22:13 +0530, Singh, Gaurav K wrote:
> > > >
> > > > On 1/4/2018 2:48 AM, Rodrigo Vivi wrote:
> > > > > On Wed, Jan 03, 2018 at 08:31:10PM +, Pandiyan, Dhinakaran
> > wrote:
> > > > >> On Thu, 2018-01-04 at 00:48 +0530, Gaurav K Singh wrote:
> > > > >>> From: Gaurav Singh 
> > > > >>>
> > > > >>> On Apollolake, with stress test warm reboot, audio card was
> > > > >>> not getting enumerated after reboot. This was a
> > > > >> The problem looks similar to
> > > > >> https://lists.freedesktop.org/archives/intel-gfx/2017-October/1
> > > > >> 4449
> > > > >> 5.html
> > > > >>
> > > > >> although the proposed solutions are vastly different. I have
> > > > >> Cc'd some more people.
> > > > >>
> > > > >>> spurious issue happening on Apollolake. HW codec and HD audio
> > > > >>> controller link was going out of sync for which there was a
> > > > >>> fix in
> > > > >>> i915 driver but was not getting invoked for BXT. Extending
> > > > >>> this fix to BXT as well.
> > > > >>>
> > > > >>> Tested on apollolake chromebook by stress test warm reboot
> > > > >>> with
> > > > >>> 2500 iterations.
> > > > >>>
> > > > >>> Signed-off-by: Gaurav K Singh 
> > > > >>> ---
> > > > >>>   drivers/gpu/drm/i915/intel_audio.c | 2 +-
> > > > >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >>>
> > > > >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > > >>> b/drivers/gpu/drm/i915/intel_audio.c
> > > > >>> index f1502a0188eb..c71c04e1c3f6 100644
> > > > >>> --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > >>> +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > >>> @@ -729,7 +729,7 @@ static void
> > > i915_audio_component_codec_wake_override(struct device *kdev,
> > > > >>> struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> > > > >>> u32 tmp;
> > > > >>>
> > > > >>> -   if (!IS_GEN9_BC(dev_priv))
> > > > >>> +   if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv))
> > > > >> IS_GEN9()? GLK might need this too.
> > > > > I think this is applicable for all Gen9 platforms.
> > > >
> > > > > if GLK need there is the possibility of CNL also needing it...
> > > > > So not sure where to stop.
> > > > >
> > > > > Also looking to the original 

Re: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT

[Mullah, Abid A]

Yes. It will be needed for BXT also.

-Original Message-
From: Runyan, Arthur J 
Sent: Tuesday, February 27, 2018 8:49 AM
To: Pandiyan, Dhinakaran ; Singh, Gaurav K 
; Mullah, Abid A ; 
Neelagandan, Harigaran 
Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ; 
Nikula, Jani 
Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT

Abid or Hari, please check.  There was a workaround to set AUD_CHICKENBIT_REG 
bit 15 (Codec Wake overwrite to DACFEUNIT) on SKL and KBL.  Does it apply to 
BXT also?

> -Original Message-
> From: Pandiyan, Dhinakaran
> Sent: Monday, 26 February, 2018 6:04 PM
> To: Runyan, Arthur J ; Singh, Gaurav K 
> 
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo 
> ; Nikula, Jani 
> Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> 
> 
> > -Original Message-
> > From: Runyan, Arthur J
> > Sent: Tuesday, January 9, 2018 11:55 AM
> > To: Pandiyan, Dhinakaran ; Singh,
> Gaurav K
> > 
> > Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo 
> > 
> > Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> >
> > Sorry, I've been out.  I'm checking on this.
> 
> 
> Hi Art,
> 
> Is AUD_CHICKENBIT_REG:15 needed for BXT to fix code enumeration issues?
> 
> -DK
> 
> >
> > -Original Message-
> > From: Pandiyan, Dhinakaran
> > Sent: Thursday, 4 January, 2018 2:00 PM
> > To: Singh, Gaurav K 
> > Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo 
> > ; subransu.s.pru...@intel.com; Runyan, 
> > Arthur J
> 
> > Subject: Re: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> >
> > +Art
> >
> > On Thu, 2018-01-04 at 22:13 +0530, Singh, Gaurav K wrote:
> > >
> > > On 1/4/2018 2:48 AM, Rodrigo Vivi wrote:
> > > > On Wed, Jan 03, 2018 at 08:31:10PM +, Pandiyan, Dhinakaran
> wrote:
> > > >> On Thu, 2018-01-04 at 00:48 +0530, Gaurav K Singh wrote:
> > > >>> From: Gaurav Singh 
> > > >>>
> > > >>> On Apollolake, with stress test warm reboot, audio card was 
> > > >>> not getting enumerated after reboot. This was a
> > > >> The problem looks similar to
> > > >> https://lists.freedesktop.org/archives/intel-gfx/2017-October/1
> > > >> 4449
> > > >> 5.html
> > > >>
> > > >> although the proposed solutions are vastly different. I have 
> > > >> Cc'd some more people.
> > > >>
> > > >>> spurious issue happening on Apollolake. HW codec and HD audio 
> > > >>> controller link was going out of sync for which there was a 
> > > >>> fix in
> > > >>> i915 driver but was not getting invoked for BXT. Extending 
> > > >>> this fix to BXT as well.
> > > >>>
> > > >>> Tested on apollolake chromebook by stress test warm reboot 
> > > >>> with
> > > >>> 2500 iterations.
> > > >>>
> > > >>> Signed-off-by: Gaurav K Singh 
> > > >>> ---
> > > >>>   drivers/gpu/drm/i915/intel_audio.c | 2 +-
> > > >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > >>> b/drivers/gpu/drm/i915/intel_audio.c
> > > >>> index f1502a0188eb..c71c04e1c3f6 100644
> > > >>> --- a/drivers/gpu/drm/i915/intel_audio.c
> > > >>> +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > >>> @@ -729,7 +729,7 @@ static void
> > i915_audio_component_codec_wake_override(struct device *kdev,
> > > >>>   struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> > > >>>   u32 tmp;
> > > >>>
> > > >>> - if (!IS_GEN9_BC(dev_priv))
> > > >>> + if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv))
> > > >> IS_GEN9()? GLK might need this too.
> > > > I think this is applicable for all Gen9 platforms.
> > >
> > > > if GLK need there is the possibility of CNL also needing it...
> > > > So not sure where to stop.
> > > >
> > > > Also looking to the original patch that introduced this 
> > > > function, commit '632f3ab95fe2 ("drm/i915/audio: add codec 
> > > > wakeup override enabled/disable callback")'
> > > >
> > > > it tells that the reason was:
> > > > "In SKL, HDMI/DP codec and PCH HD Audio Controller are in 
> > > > different p$ wells, so it's necessary to reset display audio 
> > > > codecs when power we$ otherwise display audio codecs will 
> > > > disappear when resume from low p$ state."
> > > >
> > > > Is this the case here on BXT?
> > > Yes, its the same case with BXT.
> > > >
> > > > Another interesting thing I noticed on Spec when searching for 
> > > > this bit was that this bit is related to an workaround on SKL/KBL/CFL...
> > > > no mention to BXT.
> > > >
> > > > "This workaround is needed for an HW issue in SKL and KBL in 
> > > > which HW 

Re: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT

[Runyan, Arthur J]

Abid or Hari, please check.  There was a workaround to set AUD_CHICKENBIT_REG 
bit 15 (Codec Wake overwrite to DACFEUNIT) on SKL and KBL.  Does it apply to 
BXT also?

> -Original Message-
> From: Pandiyan, Dhinakaran
> Sent: Monday, 26 February, 2018 6:04 PM
> To: Runyan, Arthur J ; Singh, Gaurav K
> 
> Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
> Nikula, Jani 
> Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> 
> 
> > -Original Message-
> > From: Runyan, Arthur J
> > Sent: Tuesday, January 9, 2018 11:55 AM
> > To: Pandiyan, Dhinakaran ; Singh,
> Gaurav K
> > 
> > Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo 
> > Subject: RE: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> >
> > Sorry, I've been out.  I'm checking on this.
> 
> 
> Hi Art,
> 
> Is AUD_CHICKENBIT_REG:15 needed for BXT to fix code enumeration issues?
> 
> -DK
> 
> >
> > -Original Message-
> > From: Pandiyan, Dhinakaran
> > Sent: Thursday, 4 January, 2018 2:00 PM
> > To: Singh, Gaurav K 
> > Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ;
> > subransu.s.pru...@intel.com; Runyan, Arthur J
> 
> > Subject: Re: [Intel-gfx] [PATCH] drm: i915: Fix audio issue on BXT
> >
> > +Art
> >
> > On Thu, 2018-01-04 at 22:13 +0530, Singh, Gaurav K wrote:
> > >
> > > On 1/4/2018 2:48 AM, Rodrigo Vivi wrote:
> > > > On Wed, Jan 03, 2018 at 08:31:10PM +, Pandiyan, Dhinakaran
> wrote:
> > > >> On Thu, 2018-01-04 at 00:48 +0530, Gaurav K Singh wrote:
> > > >>> From: Gaurav Singh 
> > > >>>
> > > >>> On Apollolake, with stress test warm reboot, audio card was not
> > > >>> getting enumerated after reboot. This was a
> > > >> The problem looks similar to
> > > >> https://lists.freedesktop.org/archives/intel-gfx/2017-October/14449
> > > >> 5.html
> > > >>
> > > >> although the proposed solutions are vastly different. I have Cc'd
> > > >> some more people.
> > > >>
> > > >>> spurious issue happening on Apollolake. HW codec and HD audio
> > > >>> controller link was going out of sync for which there was a fix in
> > > >>> i915 driver but was not getting invoked for BXT. Extending this
> > > >>> fix to BXT as well.
> > > >>>
> > > >>> Tested on apollolake chromebook by stress test warm reboot with
> > > >>> 2500 iterations.
> > > >>>
> > > >>> Signed-off-by: Gaurav K Singh 
> > > >>> ---
> > > >>>   drivers/gpu/drm/i915/intel_audio.c | 2 +-
> > > >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>>
> > > >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > >>> b/drivers/gpu/drm/i915/intel_audio.c
> > > >>> index f1502a0188eb..c71c04e1c3f6 100644
> > > >>> --- a/drivers/gpu/drm/i915/intel_audio.c
> > > >>> +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > >>> @@ -729,7 +729,7 @@ static void
> > i915_audio_component_codec_wake_override(struct device *kdev,
> > > >>>   struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> > > >>>   u32 tmp;
> > > >>>
> > > >>> - if (!IS_GEN9_BC(dev_priv))
> > > >>> + if (!IS_GEN9_BC(dev_priv) && !IS_BROXTON(dev_priv))
> > > >> IS_GEN9()? GLK might need this too.
> > > > I think this is applicable for all Gen9 platforms.
> > >
> > > > if GLK need there is the possibility of CNL also needing it...
> > > > So not sure where to stop.
> > > >
> > > > Also looking to the original patch that introduced this function,
> > > > commit '632f3ab95fe2 ("drm/i915/audio: add codec wakeup override
> > > > enabled/disable callback")'
> > > >
> > > > it tells that the reason was:
> > > > "In SKL, HDMI/DP codec and PCH HD Audio Controller are in different
> > > > p$ wells, so it's necessary to reset display audio codecs when power
> > > > we$ otherwise display audio codecs will disappear when resume from
> > > > low p$ state."
> > > >
> > > > Is this the case here on BXT?
> > > Yes, its the same case with BXT.
> > > >
> > > > Another interesting thing I noticed on Spec when searching for this
> > > > bit was that this bit is related to an workaround on SKL/KBL/CFL...
> > > > no mention to BXT.
> > > >
> > > > "This workaround is needed for an HW issue in SKL and KBL in which
> > > > HW codec and HD audio controller link was going out of sync."
> > > Yes, in Bspec it has been mentioned only for SKL and KBL. But without
> > > this fix, sound card was not getting enumerated for BXT.
> >
> >
> > Art,
> >
> > Can you please help us here? To summarize, the question is what platforms
> need
> > the AUD_CHICKENBIT_REG:15 bit to be set to avoid code enumeration
> failures?
> >
> > -DK
> >
> > > >
> > > > Thanks,
> > > > Rodrigo.
> > > >
> > > >>
> > > >>>   return;
> > > >>>
> > > >>>   i915_audio_component_get_power(kdev);
> > > >> 

Re: [Intel-gfx] [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Claudiu Beznea]

On 27.02.2018 17:38, Daniel Thompson wrote:
> On Tue, Feb 27, 2018 at 01:40:58PM +0200, Claudiu Beznea wrote:
>> On 27.02.2018 12:54, Daniel Thompson wrote:
>>> On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
 On 26.02.2018 11:57, Jani Nikula wrote:
> On Thu, 22 Feb 2018, Daniel Thompson  wrote:
>> On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
>>> Add PWM mode to pwm_config() function. The drivers which uses 
>>> pwm_config()
>>> were adapted to this change.
>>>
>>> Signed-off-by: Claudiu Beznea 
>>> ---
>>>  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
>>>  drivers/bus/ts-nbus.c|  2 +-
>>>  drivers/clk/clk-pwm.c|  3 ++-
>>>  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
>>>  drivers/hwmon/pwm-fan.c  |  2 +-
>>>  drivers/input/misc/max77693-haptic.c |  2 +-
>>>  drivers/input/misc/max8997_haptic.c  |  6 +-
>>>  drivers/leds/leds-pwm.c  |  5 -
>>>  drivers/media/rc/ir-rx51.c   |  5 -
>>>  drivers/media/rc/pwm-ir-tx.c |  5 -
>>>  drivers/video/backlight/lm3630a_bl.c |  4 +++-
>>>  drivers/video/backlight/lp855x_bl.c  |  4 +++-
>>>  drivers/video/backlight/lp8788_bl.c  |  5 -
>>>  drivers/video/backlight/pwm_bl.c | 11 +--
>>>  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
>>>  include/linux/pwm.h  |  6 --
>>>  16 files changed, 70 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/video/backlight/lm3630a_bl.c 
>>> b/drivers/video/backlight/lm3630a_bl.c
>>> index 2030a6b77a09..696fa25dafd2 100644
>>> --- a/drivers/video/backlight/lm3630a_bl.c
>>> +++ b/drivers/video/backlight/lm3630a_bl.c
>>> @@ -165,8 +165,10 @@ static void lm3630a_pwm_ctrl(struct lm3630a_chip 
>>> *pchip, int br, int br_max)
>>>  {
>>> unsigned int period = pchip->pdata->pwm_period;
>>> unsigned int duty = br * period / br_max;
>>> +   struct pwm_caps caps = { };
>>>  
>>> -   pwm_config(pchip->pwmd, duty, period);
>>> +   pwm_get_caps(pchip->pwmd->chip, pchip->pwmd, );
>>> +   pwm_config(pchip->pwmd, duty, period, BIT(ffs(caps.modes) - 1));
>>
>> Well... I admit I've only really looked at the patches that impact 
>> backlight but dispersing this really odd looking bit twiddling 
>> throughout the kernel doesn't strike me a great API design.
>>
>> IMHO callers should not be required to find the first set bit in
>> some specially crafted set of capability bits simply to get sane 
>> default behaviour.
>
> Agreed. IMHO the regular use case becomes rather tedious, ugly, and
> error prone.

 Using simply PWM_MODE(NORMAL) instead of BIT(ffs(caps.modes) - 1) would be 
 OK
 from your side?

 Or, what about using a function like pwm_mode_first() to get the first 
 supported
 mode by PWM channel?

 Or, would you prefer to solve this inside pwm_config() function, let's 
 say, in
 case an invalid mode is passed as argument, to let pwm_config() to choose 
 the
 first available PWM mode for PWM channel passed as argument?
>>>
>>> What is it that actually needs solving?
>>>
>>> If a driver requests normal mode and the PWM driver cannot support it
>>> why not just return an error an move on.
>> Because, simply, I wasn't aware of what these PWM client drivers needs for.
> 
> I'm afraid you have confused me here.
> 
> Didn't you just *add* the whole concept of PWM caps with your patches?
> How could any existing call site expect anything except normal mode.
> Until now there has been no possiblity to request anything else.
Agree. And agree I was confusing in previous email, sorry about that. And
agree that there was nothing before and everything should work with PWM
normal mode.

When I choose to have BIT(ffs(caps.modes)) instead of PWM_MODE(NORMAL) I
was thinking at having these pwm_config() calls working all the time having
in mind that in future the PWM controllers that these drivers use, might
change in terms of PWM supported modes.

Thank you,
Claudiu Beznea

> 
> 
>>> Put another way, what is the use case for secretly adopting a mode the
>>> caller didn't want? Under what circumstances is this a good thing?
>> No one... But I wasn't aware of what the PWM clients needs for from their PWM
>> controllers. At this moment having BIT(ffs(caps.modes)) instead of
>> PWM_MODE(NORMAL) is mostly the same since all the driver that has not 
>> explicitly
>> registered PWM caps will use PWM normal mode.
>>
>> I will use PWM_MODE(NORMAL) instead of this in all the cases if this is OK 
>> from
>> your side.
>>
>> Thank you,
>> Claudiu Beznea
>>>
>>>
>>> Daniel.
>>>
> 
___
Intel-gfx 

Re: [Intel-gfx] [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

[Daniel Thompson]

On Tue, Feb 27, 2018 at 01:40:58PM +0200, Claudiu Beznea wrote:
> On 27.02.2018 12:54, Daniel Thompson wrote:
> > On Mon, Feb 26, 2018 at 04:24:15PM +0200, Claudiu Beznea wrote:
> >> On 26.02.2018 11:57, Jani Nikula wrote:
> >>> On Thu, 22 Feb 2018, Daniel Thompson  wrote:
>  On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote:
> > Add PWM mode to pwm_config() function. The drivers which uses 
> > pwm_config()
> > were adapted to this change.
> >
> > Signed-off-by: Claudiu Beznea 
> > ---
> >  arch/arm/mach-s3c24xx/mach-rx1950.c  | 11 +--
> >  drivers/bus/ts-nbus.c|  2 +-
> >  drivers/clk/clk-pwm.c|  3 ++-
> >  drivers/gpu/drm/i915/intel_panel.c   | 17 ++---
> >  drivers/hwmon/pwm-fan.c  |  2 +-
> >  drivers/input/misc/max77693-haptic.c |  2 +-
> >  drivers/input/misc/max8997_haptic.c  |  6 +-
> >  drivers/leds/leds-pwm.c  |  5 -
> >  drivers/media/rc/ir-rx51.c   |  5 -
> >  drivers/media/rc/pwm-ir-tx.c |  5 -
> >  drivers/video/backlight/lm3630a_bl.c |  4 +++-
> >  drivers/video/backlight/lp855x_bl.c  |  4 +++-
> >  drivers/video/backlight/lp8788_bl.c  |  5 -
> >  drivers/video/backlight/pwm_bl.c | 11 +--
> >  drivers/video/fbdev/ssd1307fb.c  |  3 ++-
> >  include/linux/pwm.h  |  6 --
> >  16 files changed, 70 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/video/backlight/lm3630a_bl.c 
> > b/drivers/video/backlight/lm3630a_bl.c
> > index 2030a6b77a09..696fa25dafd2 100644
> > --- a/drivers/video/backlight/lm3630a_bl.c
> > +++ b/drivers/video/backlight/lm3630a_bl.c
> > @@ -165,8 +165,10 @@ static void lm3630a_pwm_ctrl(struct lm3630a_chip 
> > *pchip, int br, int br_max)
> >  {
> > unsigned int period = pchip->pdata->pwm_period;
> > unsigned int duty = br * period / br_max;
> > +   struct pwm_caps caps = { };
> >  
> > -   pwm_config(pchip->pwmd, duty, period);
> > +   pwm_get_caps(pchip->pwmd->chip, pchip->pwmd, );
> > +   pwm_config(pchip->pwmd, duty, period, BIT(ffs(caps.modes) - 1));
> 
>  Well... I admit I've only really looked at the patches that impact 
>  backlight but dispersing this really odd looking bit twiddling 
>  throughout the kernel doesn't strike me a great API design.
> 
>  IMHO callers should not be required to find the first set bit in
>  some specially crafted set of capability bits simply to get sane 
>  default behaviour.
> >>>
> >>> Agreed. IMHO the regular use case becomes rather tedious, ugly, and
> >>> error prone.
> >>
> >> Using simply PWM_MODE(NORMAL) instead of BIT(ffs(caps.modes) - 1) would be 
> >> OK
> >> from your side?
> >>
> >> Or, what about using a function like pwm_mode_first() to get the first 
> >> supported
> >> mode by PWM channel?
> >>
> >> Or, would you prefer to solve this inside pwm_config() function, let's 
> >> say, in
> >> case an invalid mode is passed as argument, to let pwm_config() to choose 
> >> the
> >> first available PWM mode for PWM channel passed as argument?
> > 
> > What is it that actually needs solving?
> > 
> > If a driver requests normal mode and the PWM driver cannot support it
> > why not just return an error an move on.
> Because, simply, I wasn't aware of what these PWM client drivers needs for.

I'm afraid you have confused me here.

Didn't you just *add* the whole concept of PWM caps with your patches?
How could any existing call site expect anything except normal mode.
Until now there has been no possiblity to request anything else.


> > Put another way, what is the use case for secretly adopting a mode the
> > caller didn't want? Under what circumstances is this a good thing?
> No one... But I wasn't aware of what the PWM clients needs for from their PWM
> controllers. At this moment having BIT(ffs(caps.modes)) instead of
> PWM_MODE(NORMAL) is mostly the same since all the driver that has not 
> explicitly
> registered PWM caps will use PWM normal mode.
> 
> I will use PWM_MODE(NORMAL) instead of this in all the cases if this is OK 
> from
> your side.
> 
> Thank you,
> Claudiu Beznea
> > 
> > 
> > Daniel.
> > 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 09/15] drm/i915/guc: Move check for fast memcpy_wc to relay creation

[Michał Winiarski]

On Tue, Feb 27, 2018 at 03:37:25PM +0100, Michal Wajdeczko wrote:
> On Tue, 27 Feb 2018 13:52:24 +0100, Michał Winiarski
>  wrote:
> 
> > We only need those fast memcpy_wc when we're using relay to read
> > continuous GuC log. Let's prevent the user from creating a relay if we
> > know we won't be able to keep up with GuC.
> > 
> > Signed-off-by: Michał Winiarski 
> > Cc: Chris Wilson 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Sagar Arun Kamble 
> > Cc: Michal Wajdeczko 
> > ---
> >  drivers/gpu/drm/i915/intel_guc_log.c | 20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c
> > b/drivers/gpu/drm/i915/intel_guc_log.c
> > index 4dee65692f5f..d2aca10ab986 100644
> > --- a/drivers/gpu/drm/i915/intel_guc_log.c
> > +++ b/drivers/gpu/drm/i915/intel_guc_log.c
> > @@ -452,16 +452,6 @@ int intel_guc_log_create(struct intel_guc *guc)
> > GEM_BUG_ON(guc->log.vma);
> > -   /*
> > -* We require SSE 4.1 for fast reads from the GuC log buffer and
> > -* it should be present on the chipsets supporting GuC based
> > -* submisssions.
> > -*/
> > -   if (WARN_ON(!i915_has_memcpy_from_wc())) {
> > -   ret = -EINVAL;
> > -   goto err;
> > -   }
> > -
> > vma = intel_guc_allocate_vma(guc, GUC_LOG_SIZE);
> > if (IS_ERR(vma)) {
> > ret = PTR_ERR(vma);
> > @@ -568,6 +558,16 @@ int intel_guc_log_relay_open(struct intel_guc *guc)
> > goto out_unlock;
> > }
> > +   /*
> > +* We require SSE 4.1 for fast reads from the GuC log buffer and
> > +* it should be present on the chipsets supporting GuC based
> > +* submisssions.
> > +*/
> > +   if (!i915_has_memcpy_from_wc()) {
> > +   ret = -EINVAL;
> 
> hmm, maybe -ENODEV as this is not user fault

ENODEV means that we're not using GuC.
-ENXIO?

-Michał

> 
> > +   goto out_unlock;
> > +   }
> > +
> > ret = guc_log_relay_create(guc);
> > if (ret)
> > goto out_unlock;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] igt/gem_fd_exhaustion: Actually test error handling on fd exhaustion

[Patchwork]

== Series Details ==

Series: series starting with [1/2] igt/gem_fd_exhaustion: Actually test error 
handling on fd exhaustion
URL   : https://patchwork.freedesktop.org/series/39051/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
77411862d239916b40e218eeb6519b8f31fc7f1d meson: Get rid of lib_headers

with latest DRM-Tip kernel build CI_DRM_3839
aea43a430276 drm-tip: 2018y-02m-27d-10h-49m-38s UTC integration manifest

No testlist changes.

 Possible new issues:

Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> PASS   (fi-ivb-3520m)
Subgroup force-edid:
skip   -> PASS   (fi-ivb-3520m)
Subgroup force-load-detect:
skip   -> PASS   (fi-ivb-3520m)
Subgroup prune-stale-modes:
skip   -> PASS   (fi-ivb-3520m)

 Known issues:

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

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

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:438s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:424s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:375s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:488s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:286s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:481s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:470s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:456s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:565s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:286s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:505s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:408s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:417s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:450s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:493s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:496s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:586s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:522s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:470s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:429s
fi-snb-2520m total:245  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:392s

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Poll hdcp register on sudden NACK

[Ramalingam C]

On Monday 26 February 2018 11:22 PM, Sean Paul wrote:

On Mon, Feb 26, 2018 at 10:42:38PM +0530, Ramalingam C wrote:

In a connected state, If a HDMI HDCP sink is responded with NACK for
HDCP I2C register access, then HDMI HDCP spec mandates the polling
of any HDCP space registers for accessibility, minimum once in 2Secs
atleast for 4Secs.


I'm not convinced this is the right place to do this.

The reason is that this is more complex than how you have it below. You can't
access state outside of check/commit, so polling state->content_protection is
not permissable from check_link. If the check fails, the driver will change the
current value of content_protection, so userspace will be able to retry.

In the case of enable, since it's synchronous, the error will be propagated to
userspace and it can retry if that's the right thing to do.


Sean,

I am not grasping the concern clearly. Please help me on that.

Do you want to say why do you want to poll the hdcp space register's 
availability?
Because specification is asking for it. Functionally from our usecase 
perspective no
difference with and without this NACK handling.

Retry from userspace will not help to address the failures in the CTS tests 
mentioned below.

This could be done without referring connector state.

--Ram



Sean


Just to make it simple, this is generically implemented for both HDMI
and DP. But we dont expect that this scanario will occur for DP.

HDMI HDCP CTS Tests: 1A-04 and 1A-07A.

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

diff --git a/drivers/gpu/drm/i915/intel_hdcp.c 
b/drivers/gpu/drm/i915/intel_hdcp.c
index 95081aaa832a..14be14a45e5a 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -16,6 +16,47 @@
  
  #define KEY_LOAD_TRIES	5
  
+static

+struct intel_digital_port *conn_to_dig_port(struct intel_connector *connector)
+{
+   return enc_to_dig_port(_attached_encoder(>base)->base);
+}
+
+static inline bool hdcp_port_accessible(struct intel_connector *connector)
+{
+   struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+   int ret = -ENXIO;
+   u8 bksv[DRM_HDCP_KSV_LEN];
+
+   ret = connector->hdcp_shim->read_bksv(intel_dig_port, bksv);
+   if (!ret)
+   return true;
+   return false;
+}
+
+static bool wait_for_hdcp_port(struct intel_connector *connector)
+{
+   int i, tries = 10;
+
+   for (i = 0; i < tries; i++) {
+   if (connector->base.status != connector_status_connected ||
+   connector->base.state->content_protection ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED ||
+   connector->hdcp_value ==
+   DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+   return false;
+
+   if (hdcp_port_accessible(connector))
+   break;
+
+   msleep_interruptible(500);
+   }
+
+   if (i == tries)
+   return false;
+   return true;
+}
+
  static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
  {
@@ -584,12 +625,6 @@ static int intel_hdcp_auth(struct intel_digital_port 
*intel_dig_port,
return 0;
  }
  
-static

-struct intel_digital_port *conn_to_dig_port(struct intel_connector *connector)
-{
-   return enc_to_dig_port(_attached_encoder(>base)->base);
-}
-
  static int _intel_hdcp_disable(struct intel_connector *connector)
  {
struct drm_i915_private *dev_priv = connector->base.dev->dev_private;
@@ -719,14 +754,26 @@ int intel_hdcp_init(struct intel_connector *connector,
  
  int intel_hdcp_enable(struct intel_connector *connector)

  {
-   int ret;
+   int ret, tries = 2;
  
  	if (!connector->hdcp_shim)

return -ENOENT;
  
  	mutex_lock(>hdcp_mutex);
  
+enable_hdcp:

ret = _intel_hdcp_enable(connector);
+
+   /*
+* Suddenly if sink is NACK-ed for the access of HDCP
+* registers, but display is still connected, poll for hdcp
+* port accessibility. One of the HDCP spec requirement.
+*/
+   if ((ret == -EIO || ret == -ENXIO) &&
+   connector->base.status == connector_status_connected &&
+   !hdcp_port_accessible(connector))
+   if (wait_for_hdcp_port(connector) && --tries)
+   goto enable_hdcp;
if (ret)
goto out;
  
@@ -838,6 +885,19 @@ int intel_hdcp_check_link(struct intel_connector *connector)

goto out;
}
  
+	/*

+* Suddenly if sink is NACK-ed for the access of HDCP
+* registers, but display is still connected, poll for hdcp
+* port accessibility. One of the HDCP spec requirement.
+*/
+   if (connector->base.status == 

Re: [Intel-gfx] [PATCH 09/15] drm/i915/guc: Move check for fast memcpy_wc to relay creation

[Michal Wajdeczko]

On Tue, 27 Feb 2018 13:52:24 +0100, Michał Winiarski  
 wrote:



We only need those fast memcpy_wc when we're using relay to read
continuous GuC log. Let's prevent the user from creating a relay if we
know we won't be able to keep up with GuC.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c  
b/drivers/gpu/drm/i915/intel_guc_log.c

index 4dee65692f5f..d2aca10ab986 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -452,16 +452,6 @@ int intel_guc_log_create(struct intel_guc *guc)
GEM_BUG_ON(guc->log.vma);
-   /*
-* We require SSE 4.1 for fast reads from the GuC log buffer and
-* it should be present on the chipsets supporting GuC based
-* submisssions.
-*/
-   if (WARN_ON(!i915_has_memcpy_from_wc())) {
-   ret = -EINVAL;
-   goto err;
-   }
-
vma = intel_guc_allocate_vma(guc, GUC_LOG_SIZE);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
@@ -568,6 +558,16 @@ int intel_guc_log_relay_open(struct intel_guc *guc)
goto out_unlock;
}
+   /*
+* We require SSE 4.1 for fast reads from the GuC log buffer and
+* it should be present on the chipsets supporting GuC based
+* submisssions.
+*/
+   if (!i915_has_memcpy_from_wc()) {
+   ret = -EINVAL;


hmm, maybe -ENODEV as this is not user fault


+   goto out_unlock;
+   }
+
ret = guc_log_relay_create(guc);
if (ret)
goto out_unlock;

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

Re: [Intel-gfx] [PATCH] drm/i915: Add a parameter to disable SAGV

[Jani Nikula]

On Mon, 26 Feb 2018, Rodrigo Vivi  wrote:
> On Mon, Feb 26, 2018 at 03:45:51PM -0800, Azhar Shaikh wrote:
>> SAGV handling is currently broken which can result in system hangs.
>> Add a parameter to disable SAGV, till the SAGV handling is fixed.
>
> Not just handling of the limitations we have with SAGV is broken but
> also probably some hidden DBUF config issue that is worst when SAGV
> is enabled.
>
> But also the handling broken is not a good reason for the parameter
> itself. But the good part of this is the ability to debug display
> hard hangs issues with SAGV requirements.
>
> I'm in favor of the paramenter. We just need a different justification
> here.

*cringe* at adding a parameter to workaround issues.

>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104975
>> Signed-off-by: Azhar Shaikh 
>> ---
>>  drivers/gpu/drm/i915/i915_params.c | 3 +++
>>  drivers/gpu/drm/i915/i915_params.h | 3 ++-
>>  drivers/gpu/drm/i915/intel_pm.c| 2 +-
>>  3 files changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_params.c 
>> b/drivers/gpu/drm/i915/i915_params.c
>> index 08108ce5be21..6aede52240b0 100644
>> --- a/drivers/gpu/drm/i915/i915_params.c
>> +++ b/drivers/gpu/drm/i915/i915_params.c
>> @@ -167,6 +167,9 @@ struct i915_params i915_modparams __read_mostly = {
>>  i915_param_named_unsafe(enable_dp_mst, bool, 0600,
>>  "Enable multi-stream transport (MST) for new DisplayPort sinks. 
>> (default: true)");
>>  
>> +i915_param_named_unsafe(disable_sagv, bool, 0600,
>> +"Disable SAGV (default: false)");
>> +
>
> I understand that SAGV is default to enable and enabled by BIOS so we
> actually need to disable it.
>
> However the name will cause the same old confusion as disable power well 
> disable
>
> So I'm in favor of bool i915.enable_sagv defaults to enable
> and use i915.enable_sagv=0 when we need to disable it.

Agreed, if you must use a parameter.

BR,
Jani.



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

[Intel-gfx] [PATCH i-g-t 2/2] igt/gem_fd_exhaustion: Modify fs.nr_open for duration of the test

[Karol Krol]

We also need to adjust fs.nr_open to allow setting rlimit equal to
fs.file-max. Otherwise we're getting EPREM on setrlimit().

Signed-off-by: Karol Krol 
---
 tests/gem_fd_exhaustion.c | 49 ---
 1 file changed, 42 insertions(+), 7 deletions(-)

diff --git a/tests/gem_fd_exhaustion.c b/tests/gem_fd_exhaustion.c
index 6750444e..aa3fe8b3 100644
--- a/tests/gem_fd_exhaustion.c
+++ b/tests/gem_fd_exhaustion.c
@@ -33,17 +33,44 @@
 #include 
 #include 
 
+unsigned int original_nr_open;
+
+static int read_sysctl(const char *path)
+{
+   unsigned int val;
+   FILE *f = fopen(path, "r");
+
+   if (f) {
+   igt_assert(fscanf(f, "%u", ) == 1);
+   fclose(f);
+   return val;
+   }
+   return -errno;
+}
+
+static int write_sysctl(const char *path, unsigned int val)
+{
+   FILE *f = fopen(path, "w");
+
+   if (f) {
+   igt_assert(fprintf(f, "%u", val));
+   fclose(f);
+   return 0;
+   }
+   return -errno;
+}
+
 static bool allow_unlimited_files(void)
 {
+   unsigned int nofile_rlim = 1024*1024;
struct rlimit rlim;
-   unsigned nofile_rlim = 1024*1024;
+   unsigned int buf;
 
-   FILE *file = fopen("/proc/sys/fs/file-max", "r");
-   if (file) {
-   igt_assert(fscanf(file, "%u", _rlim) == 1);
-   igt_info("System limit for open files is %u\n", nofile_rlim);
-   fclose(file);
-   }
+   buf = read_sysctl("/proc/sys/fs/file-max");
+   if (buf > 0)
+   nofile_rlim = buf;
+   original_nr_open = read_sysctl("/proc/sys/fs/nr_open");
+   igt_assert(write_sysctl("/proc/sys/fs/nr_open", nofile_rlim) == 0);
 
if (getrlimit(RLIMIT_NOFILE, ))
return false;
@@ -53,6 +80,12 @@ static bool allow_unlimited_files(void)
return setrlimit(RLIMIT_NOFILE, ) == 0;
 }
 
+static void restore_original_sysctl(void)
+{
+   if (original_nr_open > 0)
+   write_sysctl("/proc/sys/fs/nr_open", original_nr_open);
+}
+
 igt_simple_main
 {
int fd;
@@ -61,6 +94,8 @@ igt_simple_main
 
fd = drm_open_driver(DRIVER_INTEL);
 
+   igt_install_exit_handler(restore_original_sysctl);
+
igt_fork(n, 1) {
igt_drop_root();
 
-- 
2.14.3



Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

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

[Intel-gfx] [PATCH i-g-t 1/2] igt/gem_fd_exhaustion: Actually test error handling on fd exhaustion

[Karol Krol]

Long time ago, there was an issue with driver crashing due to lack of
error handling on struct file creation (gem_create()). We're unable to hit
this scenario, because dup() does not creat flip. Let's replace dup() with
open() and assert that error is returned on exhaustion.

Signed-off-by: Karol Krol 
---
 tests/gem_fd_exhaustion.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/gem_fd_exhaustion.c b/tests/gem_fd_exhaustion.c
index 0969f9c6..6750444e 100644
--- a/tests/gem_fd_exhaustion.c
+++ b/tests/gem_fd_exhaustion.c
@@ -65,7 +65,7 @@ igt_simple_main
igt_drop_root();
 
for (int i = 0; ; i++) {
-   int leak = dup(fd);
+   int leak = open("/dev/null", O_RDONLY);
uint32_t handle;
 
if (__gem_create(fd, 4096, ) == 0)
@@ -73,6 +73,8 @@ igt_simple_main
 
if (leak < 0) {
igt_info("fd exhaustion after %i rounds.\n", i);
+   igt_assert(__gem_create(fd, 4096,
+   ) == -ENFILE);
break;
}
}
-- 
2.14.3



Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). If you are not the intended recipient, please 
contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.

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

Re: [Intel-gfx] [PATCH 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay

[Michal Wajdeczko]

On Tue, 27 Feb 2018 13:52:20 +0100, Michał Winiarski  
 wrote:



Currently, we're treating relay and mapping of GuC log as a separate
concepts. We're also using inconsistent locking, sometimes using
relay_lock, sometimes using struct mutex.
Let's correct that. Anything touching the runtime is now serialized
using runtime.lock, while we're still using struct mutex as inner lock
for mapping.
We're still racy in setting the log level - but we'll take care of that
in the following patches.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---


/snip/

diff --git a/drivers/gpu/drm/i915/intel_uc.c  
b/drivers/gpu/drm/i915/intel_uc.c

index e9aba3c35264..55a9b5b673e0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -221,18 +221,24 @@ static void guc_free_load_err_log(struct intel_guc  
*guc)

int intel_uc_log_register(struct drm_i915_private *dev_priv)
 {
-   if (!USES_GUC(dev_priv) || !i915_modparams.guc_log_level)
+   int ret = 0;
+
+   if (!USES_GUC(dev_priv))
return 0;
-   return intel_guc_log_register(_priv->guc);
+   if (i915_modparams.guc_log_level)
+   ret = intel_guc_log_register(_priv->guc);
+
+   return ret;
 }
void intel_uc_log_unregister(struct drm_i915_private *dev_priv)
 {
-   if (!USES_GUC(dev_priv) || !i915_modparams.guc_log_level)
+   if (!USES_GUC(dev_priv))
return;
-   intel_guc_log_unregister(_priv->guc);
+   if (i915_modparams.guc_log_level)
+   intel_guc_log_unregister(_priv->guc);
 }
static int guc_enable_communication(struct intel_guc *guc)


this chunk can be done in patch 2/15
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/15] drm/i915/guc: Create common entry points for log register/unregister

[Michal Wajdeczko]

On Tue, 27 Feb 2018 13:52:17 +0100, Michał Winiarski  
 wrote:



We have many functions responsible for allocating different parts of
runtime called from multiple places. Let's stick with keeping


s/runtime/GuC log runtime ?


everything in guc_log_register instead.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.c  |   6 +-
 drivers/gpu/drm/i915/i915_gem.c  |   4 +-
 drivers/gpu/drm/i915/intel_guc_log.c | 148  
++-

 drivers/gpu/drm/i915/intel_guc_log.h |   6 +-
 drivers/gpu/drm/i915/intel_uc.c  |  39 -
 drivers/gpu/drm/i915/intel_uc.h  |   6 +-
 6 files changed, 91 insertions(+), 118 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c  
b/drivers/gpu/drm/i915/i915_drv.c

index aaa861b51024..719b2be73292 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -636,7 +636,7 @@ static void i915_gem_fini(struct drm_i915_private  
*dev_priv)

i915_gem_contexts_fini(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
-   intel_uc_fini_misc(dev_priv);
+   intel_uc_fini_wq(dev_priv);
i915_gem_cleanup_userptr(dev_priv);
i915_gem_drain_freed_objects(dev_priv);
@@ -1237,7 +1237,7 @@ static void i915_driver_register(struct  
drm_i915_private *dev_priv)

/* Reveal our presence to userspace */
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
-   i915_guc_log_register(dev_priv);
+   intel_uc_log_register(dev_priv);


btw, maybe we should place this function little later after

/* Depends on debugfs having been initialized */


i915_setup_sysfs(dev_priv);
/* Depends on sysfs having been initialized */
@@ -1297,7 +1297,7 @@ static void i915_driver_unregister(struct  
drm_i915_private *dev_priv)

i915_pmu_unregister(dev_priv);
i915_teardown_sysfs(dev_priv);
-   i915_guc_log_unregister(dev_priv);
+   intel_uc_log_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
i915_gem_shrinker_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c  
b/drivers/gpu/drm/i915/i915_gem.c

index 14c855b1a3a4..4bf5f25b29e2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5279,7 +5279,7 @@ int i915_gem_init(struct drm_i915_private  
*dev_priv)

if (ret)
return ret;
-   ret = intel_uc_init_misc(dev_priv);
+   ret = intel_uc_init_wq(dev_priv);
if (ret)
return ret;
@@ -5375,7 +5375,7 @@ int i915_gem_init(struct drm_i915_private  
*dev_priv)

intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
mutex_unlock(_priv->drm.struct_mutex);
-   intel_uc_fini_misc(dev_priv);
+   intel_uc_fini_wq(dev_priv);
if (ret != -EIO)
i915_gem_cleanup_userptr(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c  
b/drivers/gpu/drm/i915/intel_guc_log.c

index 22a05320817b..f1cab43d334e 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -441,7 +441,7 @@ void intel_guc_log_init_early(struct intel_guc *guc)
INIT_WORK(>log.runtime.flush_work, capture_logs_work);
 }
-int intel_guc_log_relay_create(struct intel_guc *guc)
+int guc_log_relay_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct rchan *guc_log_relay_chan;
@@ -494,7 +494,7 @@ int intel_guc_log_relay_create(struct intel_guc *guc)
return ret;
 }
-void intel_guc_log_relay_destroy(struct intel_guc *guc)
+void guc_log_relay_destroy(struct intel_guc *guc)
 {
mutex_lock(>log.runtime.relay_lock);
@@ -512,49 +512,6 @@ void intel_guc_log_relay_destroy(struct intel_guc  
*guc)

mutex_unlock(>log.runtime.relay_lock);
 }
-static int guc_log_late_setup(struct intel_guc *guc)
-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   int ret;
-
-   if (!guc_log_has_runtime(guc)) {
-   /*
-* If log was disabled at boot time, then setup needed to handle
-* log buffer flush interrupts would not have been done yet, so
-* do that now.
-*/
-   ret = intel_guc_log_relay_create(guc);
-   if (ret)
-   goto err;
-
-   mutex_lock(_priv->drm.struct_mutex);
-   intel_runtime_pm_get(dev_priv);
-   ret = guc_log_runtime_create(guc);
-   intel_runtime_pm_put(dev_priv);
-   mutex_unlock(_priv->drm.struct_mutex);
-
-   if (ret)
-   goto err_relay;
-   }
-
-  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Try to make display info less nuts

[Patchwork]

== Series Details ==

Series: drm: Try to make display info less nuts
URL   : https://patchwork.freedesktop.org/series/39046/
State : success

== Summary ==

Series 39046v1 drm: Try to make display info less nuts
https://patchwork.freedesktop.org/api/1.0/series/39046/revisions/1/mbox/

 Possible new issues:

Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> PASS   (fi-ivb-3520m)
Subgroup force-edid:
skip   -> PASS   (fi-ivb-3520m)
Subgroup force-load-detect:
skip   -> PASS   (fi-ivb-3520m)
Subgroup prune-stale-modes:
skip   -> PASS   (fi-ivb-3520m)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> FAIL   (fi-byt-n2820) fdo#104008

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

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:435s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:423s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:482s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:283s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:481s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:480s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:248  dwarn:0   dfail:0   fail:1   skip:39  
time:453s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:391s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:560s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:578s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:414s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:282s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:504s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:406s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:407s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:410s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:449s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:492s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:445s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:496s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:587s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:425s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:500s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:516s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:407s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:427s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:524s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:397s

aea43a430276951b4e164501e2cf8da77f6b2171 drm-tip: 2018y-02m-27d-10h-49m-38s UTC 
integration manifest
6cf08f3a12a8 drm: Sprinkle lockdep asserts for edid/display_info
05c6e870f57c drm: Fix debugfs edid_override locking
12b7d587de55 drm: Fix getconnector locking
86d967f31887 drm: Add drm_connector_fill_modes()
42718b893517 drm/probe-helper: Avoid iterating the list twice on ww backoff
09bef27fea8e drm/edid: Don't call drm_add_display_info() with an invalid EDID
c4973ec8caa9 drm/edid: Clear display info fully
32090968f316 drm: Split the display info into static and dynamic parts
3418965fb263 drm/shmobile: Don't fill display_info.{width, height}_mm at init 
time
f85fbf074f2f drm/i915: Fill display_info.{width, height}_mm from .get_modes()
4b0f7558b828 drm/gma500: Fill display_info.{width, height}_mm from .get_modes()

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] tests/testdisplay: Explicitly use GLIB_CFLAGS

[Arkadiusz Hiler]

On Tue, Feb 27, 2018 at 03:38:58PM +0200, Petri Latvala wrote:
> On Mon, Feb 05, 2018 at 12:56:10PM +0100, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > testdisplay.h includes the glib.h header file but the Makefile does not
> > explicitly pass a -I option with the path containing that header, hence
> > causing the build to fail. Note that this doesn't seem to happen with a
> > recent enough version of cairo, which implicitly provides the correct
> > -I option.
> 
> 
> Hmm. We only have GLIB_CFLAGS when HAVE_GLIB, but testdisplay is
> always built. Same for intel_dp_compliance.
> 
> Should we make glib mandatory as well? Arek, thoughts?

Yep, making sounds good. It's extremely common and we use it also for
the igtrc handling.

This allows us to remove quite a few more ifdefs and will make couple of
pending reworks easier :-)

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

Re: [Intel-gfx] [PATCH 01/15] drm/i915/guc: Tidy guc_log_control

[Michal Wajdeczko]

On Tue, 27 Feb 2018 13:52:16 +0100, Michał Winiarski  
 wrote:



We plan to decouple log runtime (mapping + relay) from verbosity control.
Let's tidy the code now to reduce the churn in the following patches.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
---


/snip/


+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -657,52 +657,55 @@ void intel_guc_log_destroy(struct intel_guc *guc)
i915_vma_unpin_and_release(>log.vma);
 }
-int intel_guc_log_control(struct intel_guc *guc, u64 control_val)
+int intel_guc_log_control_get(struct intel_guc *guc)


Can we add kernel-doc for this new function?


+{
+   GEM_BUG_ON(!guc->log.vma);
+   GEM_BUG_ON(i915_modparams.guc_log_level < 0);
+
+   return i915_modparams.guc_log_level;
+}
+
+#define GUC_LOG_IS_ENABLED(x)  (x > 0)


1) x must be wrapped into (x)
2) GUC_LOG_ prefix is misleading, maybe LOG_LEVEL_TO_ENABLED()

+#define GUC_LOG_LEVEL_TO_VERBOSITY(x)	(GUC_LOG_IS_ENABLED(x) ? x - 1 :  
0)


1) x must be wrapped into (x)
2) try to avoid double evaluation of x


+int intel_guc_log_control_set(struct intel_guc *guc, u64 val)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   bool enable_logging = control_val > 0;
-   u32 verbosity;
int ret;
-   if (!guc->log.vma)
-   return -ENODEV;
+   BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN != 0);
+   GEM_BUG_ON(!guc->log.vma);
+   GEM_BUG_ON(i915_modparams.guc_log_level < 0);
-   BUILD_BUG_ON(GUC_LOG_VERBOSITY_MIN);
-   if (control_val > 1 + GUC_LOG_VERBOSITY_MAX)
+   /*
+* GuC is recognizing log levels starting from 0 to max, we're using 0
+* as indication that logging should be disablded.


typo


+*/
+   if (GUC_LOG_LEVEL_TO_VERBOSITY(val) < GUC_LOG_VERBOSITY_MIN ||
+   GUC_LOG_LEVEL_TO_VERBOSITY(val) > GUC_LOG_VERBOSITY_MAX)


try to use helper variable easier read:

int verbosity = LOG_LEVEL_TO_VERBOSITY(val);
if (verbosity < GUC_LOG_VERBOSITY_MIN || verbosity > GUC_LOG_VERBOSITY_MAX)


return -EINVAL;
-   /* This combination doesn't make sense & won't have any effect */
-   if (!enable_logging && !i915_modparams.guc_log_level)
-   return 0;
+   mutex_lock(_priv->drm.struct_mutex);
-   verbosity = enable_logging ? control_val - 1 : 0;
+   if (i915_modparams.guc_log_level == val) {
+   ret = 0;
+   goto out_unlock;
+   }
-   ret = mutex_lock_interruptible(_priv->drm.struct_mutex);
-   if (ret)
-   return ret;
intel_runtime_pm_get(dev_priv);
-   ret = guc_log_control(guc, enable_logging, verbosity);
+   ret = guc_log_control(guc, GUC_LOG_IS_ENABLED(val),
+ GUC_LOG_LEVEL_TO_VERBOSITY(val));
intel_runtime_pm_put(dev_priv);
-   mutex_unlock(_priv->drm.struct_mutex);
+   if (ret)
+   goto out_unlock;
-   if (ret < 0) {
-   DRM_DEBUG_DRIVER("guc_logging_control action failed %d\n", ret);
-   return ret;
-   }
+   i915_modparams.guc_log_level = val;
-   if (enable_logging) {
-   i915_modparams.guc_log_level = 1 + verbosity;
+   mutex_unlock(_priv->drm.struct_mutex);
-   /*
-* If log was disabled at boot time, then the relay channel file
-* wouldn't have been created by now and interrupts also would
-* not have been enabled. Try again now, just in case.
-*/
+   if (GUC_LOG_IS_ENABLED(val) && !guc_log_has_runtime(guc)) {
ret = guc_log_late_setup(guc);
-   if (ret < 0) {
-   DRM_DEBUG_DRIVER("GuC log late setup failed %d\n", ret);


why do you want to remove all these diagnostic messages?


-   return ret;
-   }
+   if (ret)
+   goto out;
/* GuC logging is currently the only user of Guc2Host 
interrupts */
mutex_lock(_priv->drm.struct_mutex);
@@ -710,7 +713,7 @@ int intel_guc_log_control(struct intel_guc *guc, u64  
control_val)

gen9_enable_guc_interrupts(dev_priv);
intel_runtime_pm_put(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
-   } else {
+   } else if (!GUC_LOG_IS_ENABLED(val) && guc_log_has_runtime(guc)) {
/*
 * Once logging is disabled, GuC won't generate logs & send an
 * interrupt. But there could be some data in the log buffer
@@ -718,11 +721,13 @@ int intel_guc_log_control(struct intel_guc *guc,  
u64 control_val)

 * buffer state and then collect the left over logs.
 */

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/15] drm/i915/guc: Tidy guc_log_control

[Patchwork]

== Series Details ==

Series: series starting with [01/15] drm/i915/guc: Tidy guc_log_control
URL   : https://patchwork.freedesktop.org/series/39043/
State : success

== Summary ==

Series 39043v1 series starting with [01/15] drm/i915/guc: Tidy guc_log_control
https://patchwork.freedesktop.org/api/1.0/series/39043/revisions/1/mbox/

 Possible new issues:

Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> PASS   (fi-ivb-3520m)
Subgroup force-edid:
skip   -> PASS   (fi-ivb-3520m)
Subgroup force-load-detect:
skip   -> PASS   (fi-ivb-3520m)
Subgroup prune-stale-modes:
skip   -> PASS   (fi-ivb-3520m)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:288  pass:265  dwarn:0   dfail:0   fail:2   skip:21  
time:433s
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:422s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:373s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:480s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:282s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:479s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:463s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:451s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:396s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:566s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:572s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:408s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:407s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:406s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:452s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:415s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:451s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:484s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:491s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:581s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:422s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:499s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:514s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:403s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:523s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:388s

aea43a430276951b4e164501e2cf8da77f6b2171 drm-tip: 2018y-02m-27d-10h-49m-38s UTC 
integration manifest
bde0314dd456 HAX enable guc and guc_log for CI
50cbd6d95934 drm/i915/guc: Default to non-verbose GuC logging
65e605e11927 drm/i915/guc: Allow user to control default GuC logging
f0fd888f87f6 drm/i915/guc: Don't print out relay statistics when relay is 
disabled
9d58e4ac0366 drm/i915/guc: Always print log stats in i915_guc_info when using 
GuC
0395d64502af drm/i915/guc: Get rid of GuC log runtime
079743a1f59a drm/i915/guc: Move check for fast memcpy_wc to relay creation
646fae217a95 drm/i915/guc: Split relay control and GuC log level
8c2c0ef86d71 drm/i915/guc: Flush directly in log unregister
0eaa7cb72b6e drm/i915/guc: Merge log relay file and channel creation
712a23a3cbac drm/i915/guc: Log runtime should consist of both mapping and relay
e9ca940f8eec drm/i915/guc: Keep GuC interrupts enabled when using GuC
0664e85e3183 drm/i915/guc: Move GuC 

Re: [Intel-gfx] [PATCH igt v2] igt/gem_exec_schedule: Exercise "deep" preemption

[Chris Wilson]

Quoting Mika Kuoppala (2018-02-27 13:25:35)
> >   uint32_t result = gem_create(fd, 4096);
> > @@ -981,12 +1117,26 @@ igt_main
> >   igt_subtest_f("preempt-contexts-%s", 
> > e->name)
> >   preempt(fd, e->exec_id | 
> > e->flags, NEW_CTX);
> >  
> > - igt_subtest_f("preempt-other-%s", 
> > e->name)
> > - preempt_other(fd, e->exec_id 
> > | e->flags);
> > -
> >   igt_subtest_f("preempt-self-%s", 
> > e->name)
> >   preempt_self(fd, e->exec_id | 
> > e->flags);
> >  
> > + igt_subtest_f("preempt-other-%s", 
> > e->name)
> > + preempt_other(fd, e->exec_id 
> > | e->flags, 0);
> > +
> > + 
> > igt_subtest_f("preempt-other-chain-%s", e->name)
> > + preempt_other(fd, e->exec_id 
> > | e->flags, CHAIN);
> > +
> > + igt_subtest_f("preempt-queue-%s", 
> > e->name)
> > + preempt_queue(fd, e->exec_id 
> > | e->flags, 0);
> > +
> > + 
> > igt_subtest_f("preempt-queue-chain-%s", e->name)
> > + preempt_queue(fd, e->exec_id 
> > | e->flags, CHAIN);
> > + igt_subtest_f("preempt-contexts-%s", 
> > e->name)
> 
> This will collide with the same name as the test above:
> preempt(fd, e->exec_id | e->flags, NEW_CTX);

Imagine it as preempt-queue-contexts-* then. Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] tests/testdisplay: Explicitly use GLIB_CFLAGS

[Petri Latvala]

On Mon, Feb 05, 2018 at 12:56:10PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> testdisplay.h includes the glib.h header file but the Makefile does not
> explicitly pass a -I option with the path containing that header, hence
> causing the build to fail. Note that this doesn't seem to happen with a
> recent enough version of cairo, which implicitly provides the correct
> -I option.


Hmm. We only have GLIB_CFLAGS when HAVE_GLIB, but testdisplay is
always built. Same for intel_dp_compliance.

Should we make glib mandatory as well? Arek, thoughts?


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

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/15] drm/i915/guc: Tidy guc_log_control

[Patchwork]

== Series Details ==

Series: series starting with [01/15] drm/i915/guc: Tidy guc_log_control
URL   : https://patchwork.freedesktop.org/series/39043/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/guc: Tidy guc_log_control
Okay!

Commit: drm/i915/guc: Create common entry points for log register/unregister
+drivers/gpu/drm/i915/intel_guc_log.c:444:5: warning: symbol 
'guc_log_relay_create' was not declared. Should it be static?
+drivers/gpu/drm/i915/intel_guc_log.c:497:6: warning: symbol 
'guc_log_relay_destroy' was not declared. Should it be static?

Commit: drm/i915/guc: Move GuC notification handling to separate function
Okay!

Commit: drm/i915/guc: Keep GuC interrupts enabled when using GuC
Okay!

Commit: drm/i915/guc: Log runtime should consist of both mapping and relay
-O:drivers/gpu/drm/i915/intel_guc_log.c:497:6: warning: symbol 
'guc_log_relay_destroy' was not declared. Should it be static?
+drivers/gpu/drm/i915/intel_guc_log.c:459:6: warning: symbol 
'guc_log_relay_destroy' was not declared. Should it be static?

Commit: drm/i915/guc: Merge log relay file and channel creation
Okay!

Commit: drm/i915/guc: Flush directly in log unregister
Okay!

Commit: drm/i915/guc: Split relay control and GuC log level
Okay!

Commit: drm/i915/guc: Move check for fast memcpy_wc to relay creation
Okay!

Commit: drm/i915/guc: Get rid of GuC log runtime
-O:drivers/gpu/drm/i915/intel_guc_log.c:376:5: warning: symbol 
'guc_log_relay_create' was not declared. Should it be static?
-O:drivers/gpu/drm/i915/intel_guc_log.c:423:6: warning: symbol 
'guc_log_relay_destroy' was not declared. Should it be static?
+drivers/gpu/drm/i915/intel_guc_log.c:376:5: warning: symbol 
'guc_log_relay_create' was not declared. Should it be static?
+drivers/gpu/drm/i915/intel_guc_log.c:423:6: warning: symbol 
'guc_log_relay_destroy' was not declared. Should it be static?

Commit: drm/i915/guc: Always print log stats in i915_guc_info when using GuC
Okay!

Commit: drm/i915/guc: Don't print out relay statistics when relay is disabled
Okay!

Commit: drm/i915/guc: Allow user to control default GuC logging
Okay!

Commit: drm/i915/guc: Default to non-verbose GuC logging
Okay!

Commit: HAX enable guc and guc_log for CI
Okay!

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for HDCP1.4 fixes (rev2)

[Patchwork]

== Series Details ==

Series: HDCP1.4 fixes (rev2)
URL   : https://patchwork.freedesktop.org/series/38978/
State : failure

== Summary ==

Applying: drm/i915: Read HDCP R0 thrice in case of mismatch
Applying: drm/i915: read Vprime thrice incase of mismatch
Applying: drm/i915: Check hdcp key loadability
Applying: drm/i915: Poll hdcp register on sudden NACK
Applying: drm/i915: Move hdcp msg detection into shim
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_dp.c
M   drivers/gpu/drm/i915/intel_hdcp.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_hdcp.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_hdcp.c
Auto-merging drivers/gpu/drm/i915/intel_dp.c
Patch failed at 0005 drm/i915: Move hdcp msg detection into shim
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH igt v2] igt/gem_exec_schedule: Exercise "deep" preemption

[Mika Kuoppala]

Chris Wilson  writes:

> In investigating the issue with having to force preemption within the
> executing ELSP[], we want to trigger preemption between all elements of
> that array. To that end, we issue a series of requests with different
> priorities to fill the in-flight ELSP[] and then demand preemption into
> the middle of that series. One can think of even more complicated
> reordering requirements of ELSP[], trying to switch between every
> possible combination of permutations. Rather than check all 2 billion
> combinations, be content with a few.
>
> v2: Add a different pattern for queued requests. Not only do we need to
> inject a request into the middle of a single context with a queue of
> different priority contexts, but we also want a queue of different
> contexts, as they have different patterns of ELSP[] behaviour.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Michał Winiarski 
> ---
>  tests/gem_exec_schedule.c | 188 
> +-
>  1 file changed, 169 insertions(+), 19 deletions(-)
>
> diff --git a/tests/gem_exec_schedule.c b/tests/gem_exec_schedule.c
> index 8a69ab5c..7f1bda42 100644
> --- a/tests/gem_exec_schedule.c
> +++ b/tests/gem_exec_schedule.c
> @@ -373,13 +373,78 @@ static void preempt(int fd, unsigned ring, unsigned 
> flags)
>   gem_close(fd, result);
>  }
>  
> -static void preempt_other(int fd, unsigned ring)
> +#define CHAIN 0x1
> +#define CONTEXTS 0x2
> +
> +static igt_spin_t *__noise(int fd, uint32_t ctx, int prio, igt_spin_t *spin)
> +{
> + unsigned other;
> +
> + gem_context_set_priority(fd, ctx, prio);
> +
> + for_each_physical_engine(fd, other) {
> + if (spin == NULL) {
> + spin = __igt_spin_batch_new(fd, ctx, other, 0);
> + } else {
> + struct drm_i915_gem_exec_object2 obj = {
> + .handle = spin->handle,
> + };
> + struct drm_i915_gem_execbuffer2 eb = {
> + .buffer_count = 1,
> + .buffers_ptr = to_user_pointer(),
> + .rsvd1 = ctx,
> + .flags = other,
> + };
> + gem_execbuf(fd, );
> + }
> + }
> +
> + return spin;
> +}
> +
> +static void __preempt_other(int fd,
> + uint32_t *ctx,
> + unsigned int target, unsigned int primary,
> + unsigned flags)
>  {
>   uint32_t result = gem_create(fd, 4096);
>   uint32_t *ptr = gem_mmap__gtt(fd, result, 4096, PROT_READ);
> - igt_spin_t *spin[MAX_ENGINES];
> - unsigned int other;
> - unsigned int n, i;
> + unsigned int n, i, other;
> +
> + n = 0;
> + store_dword(fd, ctx[LO], primary,
> + result, (n + 1)*sizeof(uint32_t), n + 1,
> + 0, I915_GEM_DOMAIN_RENDER);
> + n++;
> +
> + if (flags & CHAIN) {
> + for_each_physical_engine(fd, other) {
> + store_dword(fd, ctx[LO], other,
> + result, (n + 1)*sizeof(uint32_t), n + 1,
> + 0, I915_GEM_DOMAIN_RENDER);
> + n++;
> + }
> + }
> +
> + store_dword(fd, ctx[HI], target,
> + result, (n + 1)*sizeof(uint32_t), n + 1,
> + 0, I915_GEM_DOMAIN_RENDER);
> +
> + igt_debugfs_dump(fd, "i915_engine_info");
> + gem_set_domain(fd, result, I915_GEM_DOMAIN_GTT, 0);
> +
> + n++;
> + for (i = 0; i <= n; i++)
> + igt_assert_eq_u32(ptr[i], i);
> +
> + munmap(ptr, 4096);
> + gem_close(fd, result);
> +}
> +
> +static void preempt_other(int fd, unsigned ring, unsigned int flags)
> +{
> + unsigned int primary;
> + igt_spin_t *spin = NULL;
>   uint32_t ctx[3];
>  
>   /* On each engine, insert
> @@ -396,36 +461,97 @@ static void preempt_other(int fd, unsigned ring)
>   gem_context_set_priority(fd, ctx[LO], MIN_PRIO);
>  
>   ctx[NOISE] = gem_context_create(fd);
> + spin = __noise(fd, ctx[NOISE], 0, NULL);
>  
>   ctx[HI] = gem_context_create(fd);
>   gem_context_set_priority(fd, ctx[HI], MAX_PRIO);
>  
> + for_each_physical_engine(fd, primary) {
> + igt_debug("Primary engine: %s\n", e__->name);
> + __preempt_other(fd, ctx, ring, primary, flags);
> +
> + }
> +
> + igt_assert(gem_bo_busy(fd, spin->handle));
> + igt_spin_batch_free(fd, spin);
> +
> + gem_context_destroy(fd, ctx[LO]);
> + gem_context_destroy(fd, ctx[NOISE]);
> + gem_context_destroy(fd, ctx[HI]);
> +}
> +
> +static void __preempt_queue(int fd,
> + unsigned target, unsigned primary,
> + unsigned depth, unsigned flags)

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: move link rate arrays where they're used

[Patchwork]

== Series Details ==

Series: drm/i915/dp: move link rate arrays where they're used
URL   : https://patchwork.freedesktop.org/series/39032/
State : success

== Summary ==

Series 39032v1 drm/i915/dp: move link rate arrays where they're used
https://patchwork.freedesktop.org/api/1.0/series/39032/revisions/1/mbox/

 Possible new issues:

Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> PASS   (fi-ivb-3520m)
Subgroup force-edid:
skip   -> PASS   (fi-ivb-3520m)
Subgroup force-load-detect:
skip   -> PASS   (fi-ivb-3520m)
Subgroup prune-stale-modes:
skip   -> PASS   (fi-ivb-3520m)

 Known issues:

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> FAIL   (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-bdw-5557u) fdo#104162
Subgroup suspend-read-crc-pipe-c:
incomplete -> PASS   (fi-bxt-dsi) fdo#103927

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

fi-bdw-5557u total:245  pass:227  dwarn:0   dfail:0   fail:0   skip:17 
fi-bdw-gvtdvmtotal:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:421s
fi-blb-e6850 total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  
time:372s
fi-bsw-n3050 total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  
time:486s
fi-bwr-2160  total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 
time:285s
fi-bxt-dsi   total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  
time:472s
fi-bxt-j4205 total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-byt-j1900 total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  
time:468s
fi-byt-n2820 total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  
time:457s
fi-cfl-8700k total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:392s
fi-cfl-s2total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:569s
fi-cnl-y3total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:581s
fi-elk-e7500 total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  
time:413s
fi-gdg-551   total:288  pass:179  dwarn:0   dfail:0   fail:1   skip:108 
time:285s
fi-glk-1 total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:288  pass:259  dwarn:0   dfail:0   fail:2   skip:27  
time:410s
fi-ilk-650   total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  
time:411s
fi-ivb-3520m total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-ivb-3770  total:288  pass:255  dwarn:0   dfail:0   fail:0   skip:33  
time:419s
fi-kbl-7500u total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  
time:453s
fi-kbl-7560u total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  
time:489s
fi-kbl-7567u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-kbl-r total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:498s
fi-pnv-d510  total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  
time:582s
fi-skl-6260u total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:424s
fi-skl-6600u total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  
time:502s
fi-skl-6700hqtotal:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  
time:520s
fi-skl-6700k2total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-skl-6770hqtotal:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-guc   total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  
time:406s
fi-skl-gvtdvmtotal:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  
time:426s
fi-snb-2520m total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:522s
fi-snb-2600  total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  
time:391s

aea43a430276951b4e164501e2cf8da77f6b2171 drm-tip: 2018y-02m-27d-10h-49m-38s UTC 
integration manifest
bea5d9a1cb45 drm/i915/dp: move link rate arrays where they're used

== Logs ==

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

Re: [Intel-gfx] [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Philipp Zabel]

On Tue, 2018-02-27 at 14:56 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
> splitting the structure up into static and dynamic parts.
> 
> The static part will consist of subpixel_order, panel_orientation,
> and bus_formats.
> 
> Actually I'm not sure where bus_formats & co. fit in all this. For some
> drivers those seem to be static, even though they might fill them out
> from .get_modes().
>
> For other drivers this stuff even gets frobbed at
> runtime, making it more some kind of a bastard encoder/connector state.
> I'll just stick it into the static side so that the behaviour doesn't
> change when I start clear out the entire dynamic state with memset().

[...]
>  drivers/gpu/drm/imx/imx-ldb.c  |   4 +-
>  drivers/gpu/drm/imx/parallel-display.c |   2 +-

For imx-drm,
Acked-by: Philipp Zabel 

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

Re: [Intel-gfx] [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Maxime Ripard]

On Tue, Feb 27, 2018 at 02:56:53PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Currently we have a mix of static and dynamic information stored in
> the display info structure. That makes it rather difficult to repopulate
> the dynamic parts when a new EDID appears. Let's make life easier by
> splitting the structure up into static and dynamic parts.
> 
> The static part will consist of subpixel_order, panel_orientation,
> and bus_formats.
> 
> Actually I'm not sure where bus_formats & co. fit in all this. For some
> drivers those seem to be static, even though they might fill them out
> from .get_modes(). For other drivers this stuff even gets frobbed at
> runtime, making it more some kind of a bastard encoder/connector state.
> I'll just stick it into the static side so that the behaviour doesn't
> change when I start clear out the entire dynamic state with memset().
> 
> Cc: Keith Packard 
> Cc: Daniel Vetter 
> Cc: Hans de Goede 
> Cc: Shashank Sharma 
> Cc: Stefan Agner 
> Cc: Thierry Reding 
> Cc: Boris Brezillon 
> Cc: Philipp Zabel 
> Cc: Laurent Pinchart 
> Cc: Manfred Schlaegl 
> Cc: Marek Vasut 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Alison Wang 
> Cc: Eric Anholt 
> Cc: Linus Walleij 
> Cc: linux-renesas-...@vger.kernel.org
> Cc: Maxime Ripard 

For sun4i,
Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

[Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

[Ville Syrjala]

From: Ville Syrjälä 

edid and display_info are protected by mode_config.mutex. Add lockdep
asserts to make sure we're not accessing things w/o the lock.

FIXME: pretty sure this will blow up with amdgpu as they seem
to be doing edid updates even from the modeset path. Need to figure
out what to do about that. Maybe protect the edid/display info with
with connection_mutex instead of mode_config.mutex?

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Harry Wentland 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c| 4 
 drivers/gpu/drm/drm_edid.c | 2 ++
 drivers/gpu/drm/drm_probe_helper.c | 2 +-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 122060792b6f..a9f3536f4e94 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1374,6 +1374,8 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
size_t size = 0;
int ret;
 
+   lockdep_assert_held(>mode_config.mutex);
+
/* ignore requests to set edid when overridden */
if (connector->override_edid)
return 0;
@@ -1770,6 +1772,8 @@ void drm_connector_reset_display_info(struct 
drm_connector *connector)
 {
struct drm_display_info *info = >display_info;
 
+   lockdep_assert_held(>dev->mode_config.mutex);
+
memset(info, 0, sizeof(*info));
 }
 EXPORT_SYMBOL_GPL(drm_connector_reset_display_info);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 618093c4a039..7f9e9236114b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4440,6 +4440,8 @@ u32 drm_add_display_info(struct drm_connector *connector, 
const struct edid *edi
struct drm_display_info *info = >display_info;
u32 quirks = edid_get_quirks(edid);
 
+   lockdep_assert_held(>dev->mode_config.mutex);
+
info->width_mm = edid->width_cm * 10;
info->height_mm = edid->height_cm * 10;
 
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 7dc7e635d7e4..2a2afcf72788 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -400,7 +400,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
 
-   WARN_ON(!mutex_is_locked(>mode_config.mutex));
+   lockdep_assert_held(>mode_config.mutex);
 
drm_modeset_acquire_init(, 0);
 
-- 
2.13.6

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

[Intel-gfx] [RFC][PATCH 09/11] drm: Fix getconnector locking

[Ville Syrjala]

From: Ville Syrjälä 

The edid is protected by mode_config.mutex so extend the locking to
protect the property readout part as well.

Cc: Keith Packard 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2bf19a37dbac..122060792b6f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1624,15 +1624,12 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
if (copy_to_user(mode_ptr + copied,
 _mode, sizeof(u_mode))) {
ret = -EFAULT;
-   mutex_unlock(>mode_config.mutex);
-
goto out;
}
copied++;
}
}
out_resp->count_modes = mode_count;
-   mutex_unlock(>mode_config.mutex);
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
encoder = drm_connector_get_encoder(connector);
@@ -1650,6 +1647,8 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
drm_modeset_unlock(>mode_config.connection_mutex);
 
 out:
+   mutex_unlock(>mode_config.mutex);
+
drm_connector_put(connector);
 
return ret;
-- 
2.13.6

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

[Intel-gfx] [RFC][PATCH 10/11] drm: Fix debugfs edid_override locking

[Ville Syrjala]

From: Ville Syrjälä 

The edid is protected by mode_config.mutex. Grab the lock when frobbing
the debugfs edid_override thing.

Cc: Keith Packard 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_debugfs.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index b2482818fee8..caac17145629 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -275,11 +275,17 @@ static ssize_t connector_write(struct file *file, const 
char __user *ubuf,
 static int edid_show(struct seq_file *m, void *data)
 {
struct drm_connector *connector = m->private;
-   struct drm_property_blob *edid = connector->edid_blob_ptr;
+   struct drm_property_blob *edid;
+
+   mutex_lock(>dev->mode_config.mutex);
+
+   edid = connector->edid_blob_ptr;
 
if (connector->override_edid && edid)
seq_write(m, edid->data, edid->length);
 
+   mutex_unlock(>dev->mode_config.mutex);
+
return 0;
 }
 
@@ -305,6 +311,8 @@ static ssize_t edid_write(struct file *file, const char 
__user *ubuf,
 
edid = (struct edid *) buf;
 
+   mutex_lock(>dev->mode_config.mutex);
+
if (len == 5 && !strncmp(buf, "reset", 5)) {
connector->override_edid = false;
ret = drm_mode_connector_update_edid_property(connector, NULL);
@@ -318,6 +326,8 @@ static ssize_t edid_write(struct file *file, const char 
__user *ubuf,
connector->override_edid = true;
}
 
+   mutex_unlock(>dev->mode_config.mutex);
+
kfree(buf);
 
return (ret) ? ret : len;
-- 
2.13.6

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

[Intel-gfx] [RFC][PATCH 08/11] drm: Add drm_connector_fill_modes()

[Ville Syrjala]

From: Ville Syrjälä 

Wrap the ->fill_modes() call in a small helper that first clears out the
stale data from connector->display_info. This should guarantee that we
get consistent display_info whether or not the drivers use the EDID
based stuff to clear and fill it.

TODO: what about just after init, before anyone has called
->fill_modes()? In that case userspace could see stale data if they do
the cheap getconnector ioctl. Not sure if that's a valid concern though.

Cc: Keith Packard 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c | 44 +
 drivers/gpu/drm/drm_edid.c  | 14 +
 drivers/gpu/drm/drm_fb_helper.c |  2 +-
 drivers/gpu/drm/drm_sysfs.c |  6 +++---
 include/drm/drm_connector.h |  3 +++
 include/drm/drm_edid.h  |  1 -
 6 files changed, 48 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d8c3ef4f17da..2bf19a37dbac 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1389,7 +1389,7 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 * duplicate it rather than attempt to ensure some arbitrary
 * ordering of calls.
 */
-   drm_reset_display_info(connector);
+   drm_connector_reset_display_info(connector);
if (edid && drm_edid_is_valid(edid))
drm_add_display_info(connector, edid);
 
@@ -1594,9 +1594,9 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
 
mutex_lock(>mode_config.mutex);
if (out_resp->count_modes == 0) {
-   connector->funcs->fill_modes(connector,
-dev->mode_config.max_width,
-dev->mode_config.max_height);
+   drm_connector_fill_modes(connector,
+dev->mode_config.max_width,
+dev->mode_config.max_height);
}
 
out_resp->mm_width = connector->display_info.width_mm;
@@ -1759,3 +1759,39 @@ struct drm_tile_group *drm_mode_create_tile_group(struct 
drm_device *dev,
return tg;
 }
 EXPORT_SYMBOL(drm_mode_create_tile_group);
+
+/**
+ * drm_connector_reset_display_info - reset the connector's display info
+ * @connector: DRM connector
+ *
+ * Clear the old display info for @connector allowing the driver to
+ * repopulate it based on fresh data.
+ */
+void drm_connector_reset_display_info(struct drm_connector *connector)
+{
+   struct drm_display_info *info = >display_info;
+
+   memset(info, 0, sizeof(*info));
+}
+EXPORT_SYMBOL_GPL(drm_connector_reset_display_info);
+
+/**
+ * drm_connector_fill_modes - fill connector mode list and dynamic display info
+ * @connector: DRM connector
+ * @max_width: max width for modes
+ * @max_height: max height for modes
+ *
+ * Reset the display info and calls _connector_funcs.fill_modes() vfunc
+ * repopulate it and and the mode list.
+ *
+ * RETURNS:
+ * The number of modes found on @connector.
+ */
+int drm_connector_fill_modes(struct drm_connector *connector,
+unsigned int max_width, unsigned int max_height)
+{
+   drm_connector_reset_display_info(connector);
+
+   return connector->funcs->fill_modes(connector, max_width, max_height);
+}
+EXPORT_SYMBOL(drm_connector_fill_modes);
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 78c1f37be3db..618093c4a039 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4435,18 +4435,6 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
}
 }
 
-/* A connector has no EDID information, so we've got no EDID to compute quirks 
from. Reset
- * all of the values which would have been set from EDID
- */
-void
-drm_reset_display_info(struct drm_connector *connector)
-{
-   struct drm_display_info *info = >display_info;
-
-   memset(info, 0, sizeof(*info));
-}
-EXPORT_SYMBOL_GPL(drm_reset_display_info);
-
 u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
*edid)
 {
struct drm_display_info *info = >display_info;
@@ -4665,7 +4653,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
int num_modes = 0;
u32 quirks;
 
-   drm_reset_display_info(connector);
+   drm_connector_reset_display_info(connector);
 
if (edid == NULL) {
clear_eld(connector);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 18cb63b30e33..f3eddbbd0616 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2027,7 +2027,7 @@ static int drm_fb_helper_probe_connector_modes(struct 
drm_fb_helper *fb_helper,
 

[Intel-gfx] [RFC][PATCH 07/11] drm/probe-helper: Avoid iterating the list twice on ww backoff

[Ville Syrjala]

From: Ville Syrjälä 

If we have to backoff there's no point in going over the mode list again
to mark all the modes as stale. We can defer that until we're ready to
refresh the mode list. Avoids multiple list walks if we have to do the
locking backoff.

Cc: Keith Packard 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_probe_helper.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 527743394150..7dc7e635d7e4 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -415,10 +415,6 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
} else
WARN_ON(ret < 0);
 
-   /* set all old modes to the stale state */
-   list_for_each_entry(mode, >modes, head)
-   mode->status = MODE_STALE;
-
old_status = connector->status;
 
if (connector->force) {
@@ -472,6 +468,10 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
 
dev->mode_config.poll_running = drm_kms_helper_poll;
 
+   /* set all old modes to the stale state */
+   list_for_each_entry(mode, >modes, head)
+   mode->status = MODE_STALE;
+
if (connector->status == connector_status_disconnected) {
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, connector->name);
-- 
2.13.6

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

[Intel-gfx] [RFC][PATCH 05/11] drm/edid: Clear display info fully

[Ville Syrjala]

From: Ville Syrjälä 

Now that we have split the display info into static and dynamic parts,
we can just zero out the entire dynamic part with memset(). Previously
we were just clearing parts of it, leaving stale data in other parts
(eg. HDMI SCDC capabilities).

Also when the edid is NULL drm_add_edid_modes() bails out early skipping
the call to drm_add_display_info(). Thus we would again leave stale
data behind. To avoid that let's clear out the display info at the
very start of drm_add_edid_modes().

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Shashank Sharma 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c |  3 +--
 drivers/gpu/drm/drm_edid.c  | 23 +++
 2 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d73e97ed7dff..ddd7d978f462 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1389,10 +1389,9 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 * duplicate it rather than attempt to ensure some arbitrary
 * ordering of calls.
 */
+   drm_reset_display_info(connector);
if (edid)
drm_add_display_info(connector, edid);
-   else
-   drm_reset_display_info(connector);
 
drm_object_property_set_value(>base,
  dev->mode_config.non_desktop_property,
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 788fee4b4bf9..78c1f37be3db 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4443,37 +4443,18 @@ drm_reset_display_info(struct drm_connector *connector)
 {
struct drm_display_info *info = >display_info;
 
-   info->width_mm = 0;
-   info->height_mm = 0;
-
-   info->bpc = 0;
-   info->color_formats = 0;
-   info->cea_rev = 0;
-   info->max_tmds_clock = 0;
-   info->dvi_dual = false;
-   info->has_hdmi_infoframe = false;
-
-   info->non_desktop = 0;
+   memset(info, 0, sizeof(*info));
 }
 EXPORT_SYMBOL_GPL(drm_reset_display_info);
 
 u32 drm_add_display_info(struct drm_connector *connector, const struct edid 
*edid)
 {
struct drm_display_info *info = >display_info;
-
u32 quirks = edid_get_quirks(edid);
 
info->width_mm = edid->width_cm * 10;
info->height_mm = edid->height_cm * 10;
 
-   /* driver figures it out in this case */
-   info->bpc = 0;
-   info->color_formats = 0;
-   info->cea_rev = 0;
-   info->max_tmds_clock = 0;
-   info->dvi_dual = false;
-   info->has_hdmi_infoframe = false;
-
info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
 
DRM_DEBUG_KMS("non_desktop set to %d\n", info->non_desktop);
@@ -4684,6 +4665,8 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
int num_modes = 0;
u32 quirks;
 
+   drm_reset_display_info(connector);
+
if (edid == NULL) {
clear_eld(connector);
return 0;
-- 
2.13.6

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

[Intel-gfx] [RFC][PATCH 06/11] drm/edid: Don't call drm_add_display_info() with an invalid EDID

[Ville Syrjala]

From: Ville Syrjälä 

drm_mode_connector_update_edid_property() will call
drm_add_display_info() if an invalid edid is passed in.
This differs from the behaviour of drm_add_edid_modes() which
doesn't try to populate the display info from an invalid edid.
Adjust drm_mode_connector_update_edid_property() to match that
behaviour.

Unfortunately we have to pass the edid as non-const to
drm_mode_connector_update_edid_property() because drm_edid_is_valid()
may need to modify it :( Would be nice to one day fix up the EDID code
to not do crazy things like that.

Cc: Keith Packard 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_connector.c | 4 ++--
 include/drm/drm_connector.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ddd7d978f462..d8c3ef4f17da 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1368,7 +1368,7 @@ EXPORT_SYMBOL(drm_mode_connector_set_tile_property);
  * Zero on success, negative errno on failure.
  */
 int drm_mode_connector_update_edid_property(struct drm_connector *connector,
-   const struct edid *edid)
+   struct edid *edid)
 {
struct drm_device *dev = connector->dev;
size_t size = 0;
@@ -1390,7 +1390,7 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 * ordering of calls.
 */
drm_reset_display_info(connector);
-   if (edid)
+   if (edid && drm_edid_is_valid(edid))
drm_add_display_info(connector, edid);
 
drm_object_property_set_value(>base,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index aad3258facf2..8815ef1ce429 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1119,7 +1119,7 @@ int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 const char *path);
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
 int drm_mode_connector_update_edid_property(struct drm_connector *connector,
-   const struct edid *edid);
+   struct edid *edid);
 void drm_mode_connector_set_link_status_property(struct drm_connector 
*connector,
 uint64_t link_status);
 int drm_connector_init_panel_orientation_property(
-- 
2.13.6

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

[Intel-gfx] [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

[Ville Syrjala]

From: Ville Syrjälä 

Currently we have a mix of static and dynamic information stored in
the display info structure. That makes it rather difficult to repopulate
the dynamic parts when a new EDID appears. Let's make life easier by
splitting the structure up into static and dynamic parts.

The static part will consist of subpixel_order, panel_orientation,
and bus_formats.

Actually I'm not sure where bus_formats & co. fit in all this. For some
drivers those seem to be static, even though they might fill them out
from .get_modes(). For other drivers this stuff even gets frobbed at
runtime, making it more some kind of a bastard encoder/connector state.
I'll just stick it into the static side so that the behaviour doesn't
change when I start clear out the entire dynamic state with memset().

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Hans de Goede 
Cc: Shashank Sharma 
Cc: Stefan Agner 
Cc: Thierry Reding 
Cc: Boris Brezillon 
Cc: Philipp Zabel 
Cc: Laurent Pinchart 
Cc: Manfred Schlaegl 
Cc: Marek Vasut 
Cc: Archit Taneja 
Cc: Andrzej Hajda 
Cc: Alison Wang 
Cc: Eric Anholt 
Cc: Linus Walleij 
Cc: linux-renesas-...@vger.kernel.org
Cc: Maxime Ripard 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c   |   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   2 +-
 drivers/gpu/drm/bridge/sii902x.c   |   2 +-
 drivers/gpu/drm/bridge/tc358767.c  |   2 +-
 drivers/gpu/drm/drm_connector.c|  12 +-
 drivers/gpu/drm/drm_fb_helper.c|   2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |   2 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c|   2 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|   2 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c  |   2 +-
 drivers/gpu/drm/gma500/oaktrail_hdmi.c |   2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c |   2 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c|   2 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c|   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c|   2 +-
 drivers/gpu/drm/i915/intel_dsi.c   |   4 +-
 drivers/gpu/drm/i915/intel_dvo.c   |   2 +-
 drivers/gpu/drm/i915/intel_lvds.c  |   2 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   2 +-
 drivers/gpu/drm/imx/imx-ldb.c  |   4 +-
 drivers/gpu/drm/imx/parallel-display.c |   2 +-
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c |   6 +-
 drivers/gpu/drm/panel/panel-arm-versatile.c|   2 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c   |   8 +-
 drivers/gpu/drm/panel/panel-lvds.c |   4 +-
 .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  |   2 +-
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c|   4 +-
 drivers/gpu/drm/panel/panel-simple.c   |   4 +-
 drivers/gpu/drm/pl111/pl111_display.c  |   4 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |   4 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  |   2 +-
 drivers/gpu/drm/sun4i/sun4i_tcon.c |   4 +-
 drivers/gpu/drm/tve200/tve200_display.c|   2 +-
 drivers/gpu/drm/vc4/vc4_dpi.c  |   4 +-
 include/drm/drm_connector.h| 123 -
 36 files changed, 125 insertions(+), 106 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 74d2efaec52f..1ba72dc2a85b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1927,7 +1927,7 @@ amdgpu_connector_add(struct amdgpu_device *adev,
} else
connector->polled = DRM_CONNECTOR_POLL_HPD;
 
-   connector->display_info.subpixel_order = subpixel_order;
+   connector->static_display_info.subpixel_order = subpixel_order;
drm_connector_register(connector);
 
if (has_aux)
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c 
b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
index 120dd3b26fc2..7e9f7f1ab1b1 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_virtual.c
@@ -639,7 +639,7 @@ static int dce_virtual_connector_encoder_init(struct 
amdgpu_device *adev,
drm_connector_init(adev->ddev, connector, _virtual_connector_funcs,
   

[Intel-gfx] [RFC][PATCH 00/11] drm: Try to make display info less nuts

[Ville Syrjala]

From: Ville Syrjälä 

Currently the display info is cleared/populated in a very ad-hoc manner.
I'd like to make it more robust by making sure it gets cleared by the
core forcing drivers to repopulate in .fill_modes().

The bus_formats stuff looks very much ad-hoc all over, so I left that
out from consideration for now.

The locking around the display info and edid updates looks somewhat
busted as well, so I figured I'd sprinkle some lockdep asserts around.
That last part probably won't cooperate nicely with amdgpu as they
seem to be doing edid updates from the modeset path. So need to think
of some way to untangle that mess. Hence this is just an RFC for now.

Cc: Alison Wang 
Cc: Andrzej Hajda 
Cc: Archit Taneja 
Cc: Boris Brezillon 
Cc: Daniel Vetter 
Cc: Eric Anholt 
Cc: Hans de Goede 
Cc: Harry Wentland 
Cc: Keith Packard 
Cc: Laurent Pinchart 
Cc: Linus Walleij 
Cc: linux-renesas-...@vger.kernel.org
Cc: Manfred Schlaegl 
Cc: Marek Vasut 
Cc: Maxime Ripard 
Cc: Patrik Jakobsson 
Cc: Philipp Zabel 
Cc: Shashank Sharma 
Cc: Stefan Agner 
Cc: Thierry Reding 

Ville Syrjälä (11):
  drm/gma500: Fill display_info.{width,height}_mm from .get_modes()
  drm/i915: Fill display_info.{width,height}_mm from .get_modes()
  drm/shmobile: Don't fill display_info.{width,height}_mm at init time
  drm: Split the display info into static and dynamic parts
  drm/edid: Clear display info fully
  drm/edid: Don't call drm_add_display_info() with an invalid EDID
  drm/probe-helper: Avoid iterating the list twice on ww backoff
  drm: Add drm_connector_fill_modes()
  drm: Fix getconnector locking
  drm: Fix debugfs edid_override locking
  drm: Sprinkle lockdep asserts for edid/display_info

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c   |   2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   2 +-
 drivers/gpu/drm/bridge/sii902x.c   |   2 +-
 drivers/gpu/drm/bridge/tc358767.c  |   2 +-
 drivers/gpu/drm/drm_connector.c|  70 ---
 drivers/gpu/drm/drm_debugfs.c  |  12 +-
 drivers/gpu/drm/drm_edid.c |  35 +-
 drivers/gpu/drm/drm_fb_helper.c|   4 +-
 drivers/gpu/drm/drm_probe_helper.c |  10 +-
 drivers/gpu/drm/drm_sysfs.c|   6 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c |   2 +-
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c|   2 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|   2 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c  |  14 +--
 drivers/gpu/drm/gma500/oaktrail_hdmi.c |   2 +-
 drivers/gpu/drm/gma500/oaktrail_lvds.c |   2 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c|   2 +-
 drivers/gpu/drm/gma500/psb_intel_sdvo.c|   2 +-
 drivers/gpu/drm/i915/i915_debugfs.c|   2 +-
 drivers/gpu/drm/i915/intel_dp.c|  15 ++-
 drivers/gpu/drm/i915/intel_dsi.c   |  17 +--
 drivers/gpu/drm/i915/intel_dvo.c   |   2 +-
 drivers/gpu/drm/i915/intel_lvds.c  |  11 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   2 +-
 drivers/gpu/drm/imx/imx-ldb.c  |   4 +-
 drivers/gpu/drm/imx/parallel-display.c |   2 +-
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c |   6 +-
 drivers/gpu/drm/panel/panel-arm-versatile.c|   2 +-
 drivers/gpu/drm/panel/panel-ilitek-ili9322.c   |   8 +-
 drivers/gpu/drm/panel/panel-lvds.c |   4 +-
 .../gpu/drm/panel/panel-raspberrypi-touchscreen.c  |   2 +-
 drivers/gpu/drm/panel/panel-seiko-43wvf1g.c|   4 +-
 drivers/gpu/drm/panel/panel-simple.c   |   4 +-
 drivers/gpu/drm/pl111/pl111_display.c  |   4 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |   4 +-
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c  |   2 +-
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |   3 -
 drivers/gpu/drm/sun4i/sun4i_tcon.c |   4 +-
 drivers/gpu/drm/tve200/tve200_display.c|   2 +-
 drivers/gpu/drm/vc4/vc4_dpi.c  |   4 +-
 include/drm/drm_connector.h| 128 -
 include/drm/drm_edid.h |   1 -
 43 files changed, 227 insertions(+), 185 deletions(-)

-- 
2.13.6

___
Intel-gfx mailing list

[Intel-gfx] [RFC][PATCH 03/11] drm/shmobile: Don't fill display_info.{width, height}_mm at init time

[Ville Syrjala]

From: Ville Syrjälä 

shmobile is already populating display_info.width_mm and
display_info.height_mm from the .get_modes() hook which is what
we want. No need to populate it from the init path as well.

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: linux-renesas-...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c 
b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
index e7738939a86d..327b7965679a 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
@@ -703,9 +703,6 @@ int shmob_drm_connector_create(struct shmob_drm_device 
*sdev,
 
sdev->connector.encoder = encoder;
 
-   connector->display_info.width_mm = sdev->pdata->panel.width_mm;
-   connector->display_info.height_mm = sdev->pdata->panel.height_mm;
-
ret = drm_connector_init(sdev->ddev, connector, _funcs,
 DRM_MODE_CONNECTOR_LVDS);
if (ret < 0)
-- 
2.13.6

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

[Intel-gfx] [RFC][PATCH 01/11] drm/gma500: Fill display_info.{width, height}_mm from .get_modes()

[Ville Syrjala]

From: Ville Syrjälä 

display_info.width_mm and display_info.height_mm are dynamic metadata
that either gets parsed from the EDID or filled by the driver by some
other means. Either way we should update it in the same place, ie.
the .fill_modes()/.get_modes() hooks.

Cc: Keith Packard 
Cc: Daniel Vetter 
Cc: Patrik Jakobsson 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/gma500/mdfld_dsi_output.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index acb3848ef1c9..41e7f25ba7e0 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -336,6 +336,9 @@ static int mdfld_dsi_connector_get_modes(struct 
drm_connector *connector)
struct drm_device *dev = connector->dev;
 
if (fixed_mode) {
+   connector->display_info.width_mm = fixed_mode->width_mm;
+   connector->display_info.height_mm = fixed_mode->height_mm;
+
dev_dbg(dev->dev, "fixed_mode %dx%d\n",
fixed_mode->hdisplay, fixed_mode->vdisplay);
dup_mode = drm_mode_duplicate(dev, fixed_mode);
@@ -487,7 +490,6 @@ void mdfld_dsi_output_init(struct drm_device *dev,
struct mdfld_dsi_encoder *encoder;
struct drm_psb_private *dev_priv = dev->dev_private;
struct panel_info dsi_panel_info;
-   u32 width_mm, height_mm;
 
dev_dbg(dev->dev, "init DSI output on pipe %d\n", pipe);
 
@@ -522,9 +524,6 @@ void mdfld_dsi_output_init(struct drm_device *dev,
if (p_vid_funcs->get_panel_info(dev, pipe, _panel_info))
goto dsi_init_err0;
 
-   width_mm = dsi_panel_info.width_mm;
-   height_mm = dsi_panel_info.height_mm;
-
dsi_config->mode = dsi_config->fixed_mode;
dsi_config->connector = dsi_connector;
 
@@ -533,6 +532,9 @@ void mdfld_dsi_output_init(struct drm_device *dev,
goto dsi_init_err0;
}
 
+   dsi_config->fixed_mode->width_mm = dsi_panel_info.width_mm;
+   dsi_config->fixed_mode->height_mm = dsi_panel_info.height_mm;
+
if (pipe && dev_priv->dsi_configs[0]) {
dsi_config->dvr_ic_inited = 0;
dev_priv->dsi_configs[1] = dsi_config;
@@ -554,8 +556,6 @@ void mdfld_dsi_output_init(struct drm_device *dev,
drm_connector_helper_add(connector, _dsi_connector_helper_funcs);
 
connector->display_info.subpixel_order = SubPixelHorizontalRGB;
-   connector->display_info.width_mm = width_mm;
-   connector->display_info.height_mm = height_mm;
connector->interlace_allowed = false;
connector->doublescan_allowed = false;
 
-- 
2.13.6

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

[Intel-gfx] [RFC][PATCH 02/11] drm/i915: Fill display_info.{width, height}_mm from .get_modes()

[Ville Syrjala]

From: Ville Syrjälä 

display_info.width_mm and display_info.height_mm are dynamic metadata
that either gets parsed from the EDID or filled by the driver by some
other means. Either way we should update it in the same place, ie.
the .fill_modes()/.get_modes() hooks.

Cc: Keith Packard 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c   | 15 +++
 drivers/gpu/drm/i915/intel_dsi.c  | 13 +++--
 drivers/gpu/drm/i915/intel_lvds.c |  9 ++---
 3 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 801a21b16004..edfcad276506 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4966,6 +4966,7 @@ intel_dp_force(struct drm_connector *connector)
 static int intel_dp_get_modes(struct drm_connector *connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
+   const struct drm_display_mode *fixed_mode = 
intel_connector->panel.fixed_mode;
struct edid *edid;
 
edid = intel_connector->detect_edid;
@@ -4976,12 +4977,13 @@ static int intel_dp_get_modes(struct drm_connector 
*connector)
}
 
/* if eDP has no EDID, fall back to fixed mode */
-   if (intel_dp_is_edp(intel_attached_dp(connector)) &&
-   intel_connector->panel.fixed_mode) {
+   if (intel_dp_is_edp(intel_attached_dp(connector)) && fixed_mode) {
struct drm_display_mode *mode;
 
-   mode = drm_mode_duplicate(connector->dev,
- intel_connector->panel.fixed_mode);
+   connector->display_info.width_mm = fixed_mode->width_mm;
+   connector->display_info.height_mm = fixed_mode->height_mm;
+
+   mode = drm_mode_duplicate(connector->dev, fixed_mode);
if (mode) {
drm_mode_probed_add(connector, mode);
return 1;
@@ -6251,11 +6253,8 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
if (!fixed_mode && dev_priv->vbt.lfp_lvds_vbt_mode) {
fixed_mode = drm_mode_duplicate(dev,
dev_priv->vbt.lfp_lvds_vbt_mode);
-   if (fixed_mode) {
+   if (fixed_mode)
fixed_mode->type |= DRM_MODE_TYPE_PREFERRED;
-   connector->display_info.width_mm = fixed_mode->width_mm;
-   connector->display_info.height_mm = 
fixed_mode->height_mm;
-   }
}
mutex_unlock(>mode_config.mutex);
 
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 51a1d6868b1e..c8cf3d5c7783 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1599,17 +1599,21 @@ static void intel_dsi_unprepare(struct intel_encoder 
*encoder)
 static int intel_dsi_get_modes(struct drm_connector *connector)
 {
struct intel_connector *intel_connector = to_intel_connector(connector);
+   const struct drm_display_mode *fixed_mode =
+   intel_connector->panel.fixed_mode;
struct drm_display_mode *mode;
 
DRM_DEBUG_KMS("\n");
 
-   if (!intel_connector->panel.fixed_mode) {
+   if (!fixed_mode) {
DRM_DEBUG_KMS("no fixed mode\n");
return 0;
}
 
-   mode = drm_mode_duplicate(connector->dev,
- intel_connector->panel.fixed_mode);
+   connector->display_info.width_mm = fixed_mode->width_mm;
+   connector->display_info.height_mm = fixed_mode->height_mm;
+
+   mode = drm_mode_duplicate(connector->dev, fixed_mode);
if (!mode) {
DRM_DEBUG_KMS("drm_mode_duplicate failed\n");
return 0;
@@ -1843,9 +1847,6 @@ void intel_dsi_init(struct drm_i915_private *dev_priv)
goto err;
}
 
-   connector->display_info.width_mm = fixed_mode->width_mm;
-   connector->display_info.height_mm = fixed_mode->height_mm;
-
intel_panel_init(_connector->panel, fixed_mode, NULL, NULL);
intel_panel_setup_backlight(connector, INVALID_PIPE);
 
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index d35d2d50f595..cdae4934b885 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -477,6 +477,8 @@ intel_lvds_detect(struct drm_connector *connector, bool 
force)
 static int intel_lvds_get_modes(struct drm_connector *connector)
 {
struct intel_lvds_connector *lvds_connector = 
to_lvds_connector(connector);
+   const struct drm_display_mode *fixed_mode =
+   lvds_connector->base.panel.fixed_mode;
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode;
 
@@ -484,7 +486,10 @@ 

[Intel-gfx] [PATCH 11/15] drm/i915/guc: Always print log stats in i915_guc_info when using GuC

[Michał Winiarski]

While some of the content in this file is related to GuC submission
only, that's not the case with log related statistics.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4bd24bbe7966..866d44a091b3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2331,7 +2331,7 @@ static void i915_guc_log_info(struct seq_file *m,
 {
struct intel_guc *guc = _priv->guc;
 
-   seq_puts(m, "\nGuC logging stats:\n");
+   seq_puts(m, "GuC logging stats:\n");
 
seq_printf(m, "\tISR:   flush count %10u, overflow count %10u\n",
   guc->log.flush_count[GUC_ISR_LOG_BUFFER],
@@ -2379,14 +2379,19 @@ static int i915_guc_info(struct seq_file *m, void *data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
const struct intel_guc *guc = _priv->guc;
 
-   if (!USES_GUC_SUBMISSION(dev_priv))
+   if (!USES_GUC(dev_priv))
return -ENODEV;
 
+   i915_guc_log_info(m, dev_priv);
+
+   if (!USES_GUC_SUBMISSION(dev_priv))
+   return 0;
+
GEM_BUG_ON(!guc->execbuf_client);
 
-   seq_printf(m, "Doorbell map:\n");
+   seq_printf(m, "\nDoorbell map:\n");
seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap);
-   seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc->db_cacheline);
+   seq_printf(m, "Doorbell next cacheline: 0x%x\n", guc->db_cacheline);
 
seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client);
i915_guc_client_info(m, dev_priv, guc->execbuf_client);
@@ -2396,8 +2401,6 @@ static int i915_guc_info(struct seq_file *m, void *data)
i915_guc_client_info(m, dev_priv, guc->preempt_client);
}
 
-   i915_guc_log_info(m, dev_priv);
-
/* Add more as required ... */
 
return 0;
-- 
2.14.3

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

[Intel-gfx] [PATCH 13/15] drm/i915/guc: Allow user to control default GuC logging

[Michał Winiarski]

While both naming and actual log enable logic in GuC interface are
confusing, we can simply expose the default log as yet another log
level.
GuC logic aside, from i915 point of view we now have the following GuC
log levels:
0 Log disabled
1 Non-verbose log
2-5 Verbose log

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc.c  | 21 -
 drivers/gpu/drm/i915/intel_guc_fwif.h |  5 +++--
 drivers/gpu/drm/i915/intel_guc_log.c  |  9 +
 drivers/gpu/drm/i915/intel_guc_log.h  | 11 +++
 drivers/gpu/drm/i915/intel_uc.c   | 14 +-
 5 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 0500b4164254..83d813a6ff92 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -221,17 +221,20 @@ static u32 get_core_family(struct drm_i915_private 
*dev_priv)
}
 }
 
-static u32 get_log_verbosity_flags(void)
+static u32 get_log_control_flags(void)
 {
-   if (i915_modparams.guc_log_level > 0) {
-   u32 verbosity = i915_modparams.guc_log_level - 1;
+   u32 level = i915_modparams.guc_log_level;
+   u32 flags = 0;
 
-   GEM_BUG_ON(verbosity > GUC_LOG_VERBOSITY_MAX);
-   return verbosity << GUC_LOG_VERBOSITY_SHIFT;
-   }
+   GEM_BUG_ON(level < 0);
+
+   if (!GUC_LOG_IS_ENABLED(level))
+   flags = GUC_LOG_DEFAULT_DISABLED | GUC_LOG_DISABLED;
+   else if (GUC_LOG_IS_VERBOSE(level))
+   flags = GUC_LOG_LEVEL_TO_VERBOSITY(level) <<
+   GUC_LOG_VERBOSITY_SHIFT;
 
-   GEM_BUG_ON(i915_modparams.enable_guc < 0);
-   return GUC_LOG_DISABLED;
+   return flags;
 }
 
 /*
@@ -266,7 +269,7 @@ void intel_guc_init_params(struct intel_guc *guc)
 
params[GUC_CTL_LOG_PARAMS] = guc->log.flags;
 
-   params[GUC_CTL_DEBUG] = get_log_verbosity_flags();
+   params[GUC_CTL_DEBUG] = get_log_control_flags();
 
/* If GuC submission is enabled, set up additional parameters here */
if (USES_GUC_SUBMISSION(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 6a10aa6f04d3..4971685a2ea8 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -127,7 +127,7 @@
 #define   GUC_PROFILE_ENABLED  (1 << 7)
 #define   GUC_WQ_TRACK_ENABLED (1 << 8)
 #define   GUC_ADS_ENABLED  (1 << 9)
-#define   GUC_DEBUG_RESERVED   (1 << 10)
+#define   GUC_LOG_DEFAULT_DISABLED (1 << 10)
 #define   GUC_ADS_ADDR_SHIFT   11
 #define   GUC_ADS_ADDR_MASK0xf800
 
@@ -539,7 +539,8 @@ union guc_log_control {
u32 logging_enabled:1;
u32 reserved1:3;
u32 verbosity:4;
-   u32 reserved2:24;
+   u32 default_logging:1;
+   u32 reserved2:23;
};
u32 value;
 } __packed;
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index bdf6b3178488..ade7dadc34b8 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -58,11 +58,13 @@ static int guc_log_flush(struct intel_guc *guc)
return intel_guc_send(guc, action, ARRAY_SIZE(action));
 }
 
-static int guc_log_control(struct intel_guc *guc, bool enable, u32 verbosity)
+static int guc_log_control(struct intel_guc *guc, bool enable,
+  bool default_logging, u32 verbosity)
 {
union guc_log_control control_val = {
.logging_enabled = enable,
.verbosity = verbosity,
+   .default_logging = default_logging,
};
u32 action[] = {
INTEL_GUC_ACTION_UK_LOG_ENABLE_LOGGING,
@@ -506,8 +508,6 @@ int intel_guc_log_level_get(struct intel_guc *guc)
return i915_modparams.guc_log_level;
 }
 
-#define GUC_LOG_IS_ENABLED(x)  (x > 0)
-#define GUC_LOG_LEVEL_TO_VERBOSITY(x)  (GUC_LOG_IS_ENABLED(x) ? x - 1 : 0)
 int intel_guc_log_level_set(struct intel_guc *guc, u64 val)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -533,7 +533,8 @@ int intel_guc_log_level_set(struct intel_guc *guc, u64 val)
}
 
intel_runtime_pm_get(dev_priv);
-   ret = guc_log_control(guc, GUC_LOG_IS_ENABLED(val),
+   ret = guc_log_control(guc, GUC_LOG_IS_VERBOSE(val),
+ GUC_LOG_IS_ENABLED(val),
  GUC_LOG_LEVEL_TO_VERBOSITY(val));
intel_runtime_pm_put(dev_priv);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_guc_log.h 

[Intel-gfx] [PATCH 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled

[Michał Winiarski]

If nobody has enabled the relay, we're not comunicating with GuC, which
means that the stats don't have any meaning. Let's also remove interrupt
counter and tidy the debugfs formatting.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 47 
 drivers/gpu/drm/i915/intel_guc.c |  5 +---
 drivers/gpu/drm/i915/intel_guc_log.c | 24 +-
 drivers/gpu/drm/i915/intel_guc_log.h | 12 +
 4 files changed, 51 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 866d44a091b3..65f758f7c425 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2326,30 +2326,45 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)
return 0;
 }
 
+static const char *
+stringify_guc_log_type(enum guc_log_buffer_type type)
+{
+   switch (type) {
+   case GUC_ISR_LOG_BUFFER:
+   return "ISR";
+   case GUC_DPC_LOG_BUFFER:
+   return "DPC";
+   case GUC_CRASH_DUMP_LOG_BUFFER:
+   return "CRASH";
+   default:
+   MISSING_CASE(type);
+   }
+
+   return "";
+}
+
 static void i915_guc_log_info(struct seq_file *m,
  struct drm_i915_private *dev_priv)
 {
struct intel_guc *guc = _priv->guc;
+   enum guc_log_buffer_type type;
 
-   seq_puts(m, "GuC logging stats:\n");
-
-   seq_printf(m, "\tISR:   flush count %10u, overflow count %10u\n",
-  guc->log.flush_count[GUC_ISR_LOG_BUFFER],
-  guc->log.total_overflow_count[GUC_ISR_LOG_BUFFER]);
-
-   seq_printf(m, "\tDPC:   flush count %10u, overflow count %10u\n",
-  guc->log.flush_count[GUC_DPC_LOG_BUFFER],
-  guc->log.total_overflow_count[GUC_DPC_LOG_BUFFER]);
+   if (!intel_guc_log_relay_enabled(guc)) {
+   seq_puts(m, "GuC log relay disabled\n");
+   return;
+   }
 
-   seq_printf(m, "\tCRASH: flush count %10u, overflow count %10u\n",
-  guc->log.flush_count[GUC_CRASH_DUMP_LOG_BUFFER],
-  guc->log.total_overflow_count[GUC_CRASH_DUMP_LOG_BUFFER]);
+   seq_puts(m, "GuC logging stats:\n");
 
-   seq_printf(m, "\tTotal flush interrupt count: %u\n",
-  guc->log.flush_interrupt_count);
+   seq_printf(m, "\tRelay full count: %u\n",
+  guc->log.relay_full_count);
 
-   seq_printf(m, "\tCapture miss count: %u\n",
-  guc->log.capture_miss_count);
+   for (type = GUC_ISR_LOG_BUFFER; type < GUC_MAX_LOG_BUFFER; type++) {
+   seq_printf(m, "\t%s:\tflush count %10u, overflow count %10u\n",
+  stringify_guc_log_type(type),
+  guc->log.stats[type].flush,
+  guc->log.stats[type].overflow);
+   }
 }
 
 static void i915_guc_client_info(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index e3b6ae158a12..0500b4164254 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -388,12 +388,9 @@ void intel_guc_notification_handler(struct intel_guc *guc)
spin_unlock(>irq_lock);
 
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
-  INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) {
+  INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED))
queue_work(guc->log.flush_wq,
   >log.flush_work);
-
-   guc->log.flush_interrupt_count++;
-   }
 }
 
 int intel_guc_sample_forcewake(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index f95e18be1c5f..bdf6b3178488 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -176,22 +176,22 @@ static void *guc_get_write_buffer(struct intel_guc *guc)
return relay_reserve(guc->log.relay_chan, 0);
 }
 
-static bool guc_check_log_buf_overflow(struct intel_guc *guc,
+static bool guc_check_log_buf_overflow(struct intel_guc_log *log,
   enum guc_log_buffer_type type,
   unsigned int full_cnt)
 {
-   unsigned int prev_full_cnt = guc->log.prev_overflow_count[type];
+   unsigned int prev_full_cnt = log->stats[type].sampled_overflow;
bool overflow = false;
 
if (full_cnt != prev_full_cnt) {
overflow = true;
 
-   guc->log.prev_overflow_count[type] = full_cnt;
-   guc->log.total_overflow_count[type] += full_cnt - prev_full_cnt;
+   

[Intel-gfx] [PATCH 15/15] HAX enable guc and guc_log for CI

[Michał Winiarski]

---
 drivers/gpu/drm/i915/i915_params.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 430f5f9d0ff4..53037b5eff22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,8 +47,8 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
-   param(int, guc_log_level, 0) \
+   param(int, enable_guc, -1) \
+   param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
param(int, mmio_debug, 0) \
-- 
2.14.3

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

[Intel-gfx] [PATCH 14/15] drm/i915/guc: Default to non-verbose GuC logging

[Michał Winiarski]

Now that we've decoupled logging from relay, GuC log level is only
controlling the GuC behavior - there shouldn't be any impact on i915
behaviour. We're only going to see a single extra interrupt when log
will get half full.
That, and the fact that we're seeing igt/gem_exec_nop/basic-series
failing with non-verbose logging being disabled.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_uc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 9884a79c77bd..cd6203740c07 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -69,7 +69,7 @@ static int __get_platform_enable_guc(struct drm_i915_private 
*dev_priv)
 
 static int __get_default_guc_log_level(struct drm_i915_private *dev_priv)
 {
-   int guc_log_level = 0; /* disabled */
+   int guc_log_level = 1; /* non-verbose */
 
/* Enable if we're running on platform with GuC and debug config */
if (HAS_GUC(dev_priv) && intel_uc_is_using_guc() &&
-- 
2.14.3

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

[Intel-gfx] [PATCH 09/15] drm/i915/guc: Move check for fast memcpy_wc to relay creation

[Michał Winiarski]

We only need those fast memcpy_wc when we're using relay to read
continuous GuC log. Let's prevent the user from creating a relay if we
know we won't be able to keep up with GuC.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 4dee65692f5f..d2aca10ab986 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -452,16 +452,6 @@ int intel_guc_log_create(struct intel_guc *guc)
 
GEM_BUG_ON(guc->log.vma);
 
-   /*
-* We require SSE 4.1 for fast reads from the GuC log buffer and
-* it should be present on the chipsets supporting GuC based
-* submisssions.
-*/
-   if (WARN_ON(!i915_has_memcpy_from_wc())) {
-   ret = -EINVAL;
-   goto err;
-   }
-
vma = intel_guc_allocate_vma(guc, GUC_LOG_SIZE);
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
@@ -568,6 +558,16 @@ int intel_guc_log_relay_open(struct intel_guc *guc)
goto out_unlock;
}
 
+   /*
+* We require SSE 4.1 for fast reads from the GuC log buffer and
+* it should be present on the chipsets supporting GuC based
+* submisssions.
+*/
+   if (!i915_has_memcpy_from_wc()) {
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+
ret = guc_log_relay_create(guc);
if (ret)
goto out_unlock;
-- 
2.14.3

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

[Intel-gfx] [PATCH 08/15] drm/i915/guc: Split relay control and GuC log level

[Michał Winiarski]

Those two concepts are really separate. Since GuC is writing data into
its own buffer and we even provide a way for userspace to read directly
from it using i915_guc_log_dump debugfs, there's no real reason to tie
log level with relay creation.
Let's create a separate debugfs, giving userspace a way to create a
relay on demand, when it wants to read a continuous log rather than a
snapshot.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 56 ++
 drivers/gpu/drm/i915/i915_drv.c  |  2 -
 drivers/gpu/drm/i915/intel_guc_log.c | 76 +++-
 drivers/gpu/drm/i915/intel_guc_log.h |  9 +++--
 drivers/gpu/drm/i915/intel_uc.c  | 22 ---
 drivers/gpu/drm/i915/intel_uc.h  |  2 -
 6 files changed, 86 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 58983cafaece..4bd24bbe7966 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2496,32 +2496,73 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
return 0;
 }
 
-static int i915_guc_log_control_get(void *data, u64 *val)
+static int i915_guc_log_level_get(void *data, u64 *val)
 {
struct drm_i915_private *dev_priv = data;
 
if (!USES_GUC(dev_priv))
return -ENODEV;
 
-   *val = intel_guc_log_control_get(_priv->guc);
+   *val = intel_guc_log_level_get(_priv->guc);
 
return 0;
 }
 
-static int i915_guc_log_control_set(void *data, u64 val)
+static int i915_guc_log_level_set(void *data, u64 val)
 {
struct drm_i915_private *dev_priv = data;
 
if (!USES_GUC(dev_priv))
return -ENODEV;
 
-   return intel_guc_log_control_set(_priv->guc, val);
+   return intel_guc_log_level_set(_priv->guc, val);
 }
 
-DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_control_fops,
-   i915_guc_log_control_get, i915_guc_log_control_set,
+DEFINE_SIMPLE_ATTRIBUTE(i915_guc_log_level_fops,
+   i915_guc_log_level_get, i915_guc_log_level_set,
"%lld\n");
 
+static int i915_guc_log_relay_open(struct inode *inode, struct file *file)
+{
+   struct drm_i915_private *dev_priv = inode->i_private;
+
+   if (!USES_GUC(dev_priv))
+   return -ENODEV;
+
+   file->private_data = dev_priv;
+
+   return intel_guc_log_relay_open(_priv->guc);
+}
+
+static ssize_t
+i915_guc_log_relay_write(struct file *filp,
+const char __user *ubuf,
+size_t cnt,
+loff_t *ppos)
+{
+   struct drm_i915_private *dev_priv = filp->private_data;
+
+   intel_guc_log_relay_flush(_priv->guc);
+
+   return cnt;
+}
+
+static int i915_guc_log_relay_release(struct inode *inode, struct file *file)
+{
+   struct drm_i915_private *dev_priv = inode->i_private;
+
+   intel_guc_log_relay_close(_priv->guc);
+
+   return 0;
+}
+
+static const struct file_operations i915_guc_log_relay_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_guc_log_relay_open,
+   .write = i915_guc_log_relay_write,
+   .release = i915_guc_log_relay_release,
+};
+
 static const char *psr2_live_status(u32 val)
 {
static const char * const live_status[] = {
@@ -4761,7 +4802,8 @@ static const struct i915_debugfs_files {
{"i915_dp_test_data", _displayport_test_data_fops},
{"i915_dp_test_type", _displayport_test_type_fops},
{"i915_dp_test_active", _displayport_test_active_fops},
-   {"i915_guc_log_control", _guc_log_control_fops},
+   {"i915_guc_log_level", _guc_log_level_fops},
+   {"i915_guc_log_relay", _guc_log_relay_fops},
{"i915_hpd_storm_ctl", _hpd_storm_ctl_fops},
{"i915_ipc_status", _ipc_status_fops},
{"i915_drrs_ctl", _drrs_ctl_fops}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 719b2be73292..7ebfe7525b65 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1237,7 +1237,6 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
/* Reveal our presence to userspace */
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
-   intel_uc_log_register(dev_priv);
i915_setup_sysfs(dev_priv);
 
/* Depends on sysfs having been initialized */
@@ -1297,7 +1296,6 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
i915_pmu_unregister(dev_priv);
 
i915_teardown_sysfs(dev_priv);
-   intel_uc_log_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
 

[Intel-gfx] [PATCH 07/15] drm/i915/guc: Flush directly in log unregister

[Michał Winiarski]

Having both guc_flush_logs and guc_log_flush functions is confusing.
While we could just rename things, guc_flush_logs implementation is
quite simple. Let's get rid of it and move its content to unregister.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 35 +++
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index cbbdb400fa17..0800c5317510 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -443,25 +443,6 @@ static void guc_log_capture_logs(struct intel_guc *guc)
intel_runtime_pm_put(dev_priv);
 }
 
-static void guc_flush_logs(struct intel_guc *guc)
-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-
-   /*
-* Before initiating the forceful flush, wait for any pending/ongoing
-* flush to complete otherwise forceful flush may not actually happen.
-*/
-   flush_work(>log.runtime.flush_work);
-
-   /* Ask GuC to update the log buffer state */
-   intel_runtime_pm_get(dev_priv);
-   guc_log_flush(guc);
-   intel_runtime_pm_put(dev_priv);
-
-   /* GuC would have updated log buffer by now, so capture it */
-   guc_log_capture_logs(guc);
-}
-
 int intel_guc_log_create(struct intel_guc *guc)
 {
struct i915_vma *vma;
@@ -628,14 +609,28 @@ int intel_guc_log_register(struct intel_guc *guc)
 
 void intel_guc_log_unregister(struct intel_guc *guc)
 {
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
guc_log_flush_irq_disable(guc);
+
+   /*
+* Before initiating the forceful flush, wait for any pending/ongoing
+* flush to complete otherwise forceful flush may not actually happen.
+*/
+   flush_work(>log.runtime.flush_work);
+
/*
 * Once logging is disabled, GuC won't generate logs & send an
 * interrupt. But there could be some data in the log buffer
 * which is yet to be captured. So request GuC to update the log
 * buffer state and then collect the left over logs.
 */
-   guc_flush_logs(guc);
+   intel_runtime_pm_get(dev_priv);
+   guc_log_flush(guc);
+   intel_runtime_pm_put(dev_priv);
+
+   /* GuC would have updated log buffer by now, so capture it */
+   guc_log_capture_logs(guc);
 
mutex_lock(>log.runtime.lock);
 
-- 
2.14.3

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

[Intel-gfx] [PATCH 10/15] drm/i915/guc: Get rid of GuC log runtime

[Michał Winiarski]

Keeping a separate runtime struct is only making the code dealing with
relay less clear to read. Let's get rid of it, keeping everything in the
log instead.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc.c | 14 
 drivers/gpu/drm/i915/intel_guc_log.c | 68 ++--
 drivers/gpu/drm/i915/intel_guc_log.h | 13 +++
 3 files changed, 46 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index 41f2c3b3c482..e3b6ae158a12 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -87,9 +87,9 @@ int intel_guc_init_wq(struct intel_guc *guc)
 * or scheduled later on resume. This way the handling of work
 * item can be kept same between system suspend & rpm suspend.
 */
-   guc->log.runtime.flush_wq = alloc_ordered_workqueue("i915-guc_log",
-   WQ_HIGHPRI | WQ_FREEZABLE);
-   if (!guc->log.runtime.flush_wq) {
+   guc->log.flush_wq = alloc_ordered_workqueue("i915-guc_log",
+   WQ_HIGHPRI | WQ_FREEZABLE);
+   if (!guc->log.flush_wq) {
DRM_ERROR("Couldn't allocate workqueue for GuC log\n");
return -ENOMEM;
}
@@ -112,7 +112,7 @@ int intel_guc_init_wq(struct intel_guc *guc)
guc->preempt_wq = alloc_ordered_workqueue("i915-guc_preempt",
  WQ_HIGHPRI);
if (!guc->preempt_wq) {
-   destroy_workqueue(guc->log.runtime.flush_wq);
+   destroy_workqueue(guc->log.flush_wq);
DRM_ERROR("Couldn't allocate workqueue for GuC "
  "preemption\n");
return -ENOMEM;
@@ -130,7 +130,7 @@ void intel_guc_fini_wq(struct intel_guc *guc)
USES_GUC_SUBMISSION(dev_priv))
destroy_workqueue(guc->preempt_wq);
 
-   destroy_workqueue(guc->log.runtime.flush_wq);
+   destroy_workqueue(guc->log.flush_wq);
 }
 
 static int guc_shared_data_create(struct intel_guc *guc)
@@ -389,8 +389,8 @@ void intel_guc_notification_handler(struct intel_guc *guc)
 
if (msg & (INTEL_GUC_RECV_MSG_FLUSH_LOG_BUFFER |
   INTEL_GUC_RECV_MSG_CRASH_DUMP_POSTED)) {
-   queue_work(guc->log.runtime.flush_wq,
-  >log.runtime.flush_work);
+   queue_work(guc->log.flush_wq,
+  >log.flush_work);
 
guc->log.flush_interrupt_count++;
}
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index d2aca10ab986..f95e18be1c5f 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -156,10 +156,10 @@ static void guc_move_to_next_buf(struct intel_guc *guc)
smp_wmb();
 
/* All data has been written, so now move the offset of sub buffer. */
-   relay_reserve(guc->log.runtime.relay_chan, 
guc->log.vma->obj->base.size);
+   relay_reserve(guc->log.relay_chan, guc->log.vma->obj->base.size);
 
/* Switch to the next sub buffer */
-   relay_flush(guc->log.runtime.relay_chan);
+   relay_flush(guc->log.relay_chan);
 }
 
 static void *guc_get_write_buffer(struct intel_guc *guc)
@@ -173,7 +173,7 @@ static void *guc_get_write_buffer(struct intel_guc *guc)
 * done without using relay_reserve() along with relay_write(). So its
 * better to use relay_reserve() alone.
 */
-   return relay_reserve(guc->log.runtime.relay_chan, 0);
+   return relay_reserve(guc->log.relay_chan, 0);
 }
 
 static bool guc_check_log_buf_overflow(struct intel_guc *guc,
@@ -224,11 +224,11 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
void *src_data, *dst_data;
bool new_overflow;
 
-   if (WARN_ON(!guc->log.runtime.buf_addr))
+   if (WARN_ON(!guc->log.buf_addr))
return;
 
/* Get the pointer to shared GuC log buffer */
-   log_buf_state = src_data = guc->log.runtime.buf_addr;
+   log_buf_state = src_data = guc->log.buf_addr;
 
/* Get the pointer to local buffer to store the logs */
log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc);
@@ -316,16 +316,16 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
 static void capture_logs_work(struct work_struct *work)
 {
struct intel_guc *guc =
-   container_of(work, struct intel_guc, log.runtime.flush_work);
+   container_of(work, struct intel_guc, log.flush_work);
 
-   mutex_lock(>log.runtime.lock);
+

[Intel-gfx] [PATCH 06/15] drm/i915/guc: Merge log relay file and channel creation

[Michał Winiarski]

We have all the information we need at relay_open call time.
Since there's no reason to split the process into relay_open and
relay_late_setup_files, let's remove the extra code.

Signed-off-by: Michał Winiarski 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc_log.c | 52 
 1 file changed, 5 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 567620464f52..cbbdb400fa17 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -126,7 +126,7 @@ static struct dentry *create_buf_file_callback(const char 
*filename,
 * dentry of the file associated with the channel buffer and that file's
 * name need not be same as the filename passed as an argument.
 */
-   buf_file = debugfs_create_file("guc_log", mode,
+   buf_file = debugfs_create_file(filename, mode,
   parent, buf, _file_operations);
return buf_file;
 }
@@ -147,43 +147,6 @@ static struct rchan_callbacks relay_callbacks = {
.remove_buf_file = remove_buf_file_callback,
 };
 
-static int guc_log_relay_file_create(struct intel_guc *guc)
-{
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   struct dentry *log_dir;
-   int ret;
-
-   lockdep_assert_held(>log.runtime.lock);
-
-   /* For now create the log file in /sys/kernel/debug/dri/0 dir */
-   log_dir = dev_priv->drm.primary->debugfs_root;
-
-   /*
-* If /sys/kernel/debug/dri/0 location do not exist, then debugfs is
-* not mounted and so can't create the relay file.
-* The relay API seems to fit well with debugfs only, for availing relay
-* there are 3 requirements which can be met for debugfs file only in a
-* straightforward/clean manner :-
-* i)   Need the associated dentry pointer of the file, while opening 
the
-*  relay channel.
-* ii)  Should be able to use 'relay_file_operations' fops for the file.
-* iii) Set the 'i_private' field of file's inode to the pointer of
-*  relay channel buffer.
-*/
-   if (!log_dir) {
-   DRM_ERROR("Debugfs dir not available yet for GuC log file\n");
-   return -ENODEV;
-   }
-
-   ret = relay_late_setup_files(guc->log.runtime.relay_chan, "guc_log", 
log_dir);
-   if (ret < 0 && ret != -EEXIST) {
-   DRM_ERROR("Couldn't associate relay chan with file %d\n", ret);
-   return ret;
-   }
-
-   return 0;
-}
-
 static void guc_move_to_next_buf(struct intel_guc *guc)
 {
/*
@@ -267,7 +230,6 @@ static void guc_read_update_log_buffer(struct intel_guc 
*guc)
/* Get the pointer to shared GuC log buffer */
log_buf_state = src_data = guc->log.runtime.buf_addr;
 
-
/* Get the pointer to local buffer to store the logs */
log_buf_snapshot_state = dst_data = guc_get_write_buffer(guc);
 
@@ -436,8 +398,10 @@ int guc_log_relay_create(struct intel_guc *guc)
 * the GuC firmware logs, the channel will be linked with a file
 * later on when debugfs is registered.
 */
-   guc_log_relay_chan = relay_open(NULL, NULL, subbuf_size,
-   n_subbufs, _callbacks, dev_priv);
+   guc_log_relay_chan = relay_open("guc_log",
+   dev_priv->drm.primary->debugfs_root,
+   subbuf_size, n_subbufs,
+   _callbacks, dev_priv);
if (!guc_log_relay_chan) {
DRM_ERROR("Couldn't create relay chan for GuC logging\n");
 
@@ -648,18 +612,12 @@ int intel_guc_log_register(struct intel_guc *guc)
if (ret)
goto err_relay;
 
-   ret = guc_log_relay_file_create(guc);
-   if (ret)
-   goto err_unmap;
-
guc_log_flush_irq_enable(guc);
 
mutex_unlock(>log.runtime.lock);
 
return 0;
 
-err_unmap:
-   guc_log_unmap(guc);
 err_relay:
guc_log_relay_destroy(guc);
 err:
-- 
2.14.3

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