[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v6,1/2] drm: Add connector property to limit max bpc

2018-09-17 Thread Patchwork
== Series Details ==

Series: series starting with [v6,1/2] drm: Add connector property to limit max 
bpc
URL   : https://patchwork.freedesktop.org/series/49825/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4835 -> Patchwork_10208 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/49825/revisions/1/mbox/


== Changes ==

  No changes found


== Participating hosts (45 -> 40) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4835 -> Patchwork_10208

  CI_DRM_4835: 0875e7885717d3d812941e8e2db1dc99728be1ff @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4645: 03b90a39ed12a568c9da752466ea708d6348e110 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10208: acf42a1a4b48d551759020d1289576251c436ce0 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

acf42a1a4b48 drm/i915: Allow "max bpc" property to limit pipe_bpp
46b90fc53a4c drm: Add connector property to limit max bpc

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10208/issues.html
___
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 [v6,1/2] drm: Add connector property to limit max bpc

2018-09-17 Thread Patchwork
== Series Details ==

Series: series starting with [v6,1/2] drm: Add connector property to limit max 
bpc
URL   : https://patchwork.freedesktop.org/series/49825/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm: Add connector property to limit max bpc
+ ^~
+~~^~~~
+drivers/gpu/drm/drm_atomic.c:391:25: note: ‘crtc_state’ was declared here
+drivers/gpu/drm/drm_atomic.c:431:38: warning: ‘crtc_state’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
+drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_check_only’:
+  if (writeback_job->fb && !crtc_state->active) {
+  struct drm_crtc_state *crtc_state;

Commit: drm/i915: Allow "max bpc" property to limit pipe_bpp
Okay!

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v6,1/2] drm: Add connector property to limit max bpc

2018-09-17 Thread Patchwork
== Series Details ==

Series: series starting with [v6,1/2] drm: Add connector property to limit max 
bpc
URL   : https://patchwork.freedesktop.org/series/49825/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
46b90fc53a4c drm: Add connector property to limit max bpc
-:56: WARNING:MISSING_SPACE: break quoted strings at a space character
#56: FILE: drivers/gpu/drm/drm_atomic.c:409:
+" display bpp (was %d) to EDID 
reported"
+"max of %d\n", connector->base.id,

-:140: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!prop"
#140: FILE: drivers/gpu/drm/drm_connector.c:1603:
+   if (prop == NULL) {

-:151: CHECK:LINE_SPACING: Please don't use multiple blank lines
#151: FILE: drivers/gpu/drm/drm_connector.c:1614:
+
+

total: 0 errors, 1 warnings, 2 checks, 140 lines checked
acf42a1a4b48 drm/i915: Allow "max bpc" property to limit pipe_bpp
-:63: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#63: FILE: drivers/gpu/drm/i915/intel_display.c:10859:
+   pipe_config->pipe_bpp = 8*3;
 ^

-:67: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#67: FILE: drivers/gpu/drm/i915/intel_display.c:10863:
+   pipe_config->pipe_bpp = 10*3;
  ^

-:73: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#73: FILE: drivers/gpu/drm/i915/intel_display.c:10869:
+   pipe_config->pipe_bpp = 12*3;
  ^

-:76: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV)
#76: FILE: drivers/gpu/drm/i915/intel_display.c:10872:
+   pipe_config->pipe_bpp = 16*3;
  ^

total: 0 errors, 0 warnings, 4 checks, 92 lines checked

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


[Intel-gfx] [PATCH v6 1/2] drm: Add connector property to limit max bpc

2018-09-17 Thread Radhakrishna Sripada
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.

Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.

V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
Move the attach_property function to core(Ville)

Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Kishore Kadiyala 
Cc: Rodrigo Vivi 
Cc: Manasi Navare 
Cc: Stanislav Lisovskiy 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/drm_atomic.c| 24 
 drivers/gpu/drm/drm_atomic_helper.c |  4 
 drivers/gpu/drm/drm_atomic_uapi.c   |  4 
 drivers/gpu/drm/drm_connector.c | 34 ++
 include/drm/drm_connector.h | 20 
 5 files changed, 86 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7ada75919756..fa9996deb132 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct drm_connector 
*connector,
 {
struct drm_crtc_state *crtc_state;
struct drm_writeback_job *writeback_job = state->writeback_job;
+   struct drm_display_info *info = >display_info;
 
if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) || 
!writeback_job)
return 0;
@@ -400,6 +401,29 @@ static int drm_atomic_connector_check(struct drm_connector 
*connector,
return -EINVAL;
}
 
+   if (connector->max_bpc_property) {
+   if (info->bpc != 0 && info->bpc < state->max_requested_bpc) {
+   /* Don't use an invalid EDID bpc value */
+   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested"
+" display bpp (was %d) to EDID 
reported"
+"max of %d\n", connector->base.id,
+connector->name,
+state->max_requested_bpc, info->bpc);
+   state->max_bpc = info->bpc;
+   } else if (info->bpc != 0) {
+   state->max_bpc = state->max_requested_bpc;
+   } else {
+   /* Clamp bpc to 8 on screens witout EDID 1.4 */
+   DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested"
+" display bpp (was %d) to default 
limit"
+" of 24\n", connector->base.id,
+connector->name, 
state->max_requested_bpc);
+   state->max_bpc = 8;
+   }
+   } else {
+   state->max_bpc = info->bpc ? info->bpc : 8;
+   }
+
if (state->crtc)
crtc_state = drm_atomic_get_existing_crtc_state(state->state,
state->crtc);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3cf1aa132778..d9ce8077fb6a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->max_requested_bpc !=
+   new_connector_state->max_requested_bpc)
+   new_crtc_state->connectors_changed = true;
}
 
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..86ac33922b09 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 
return set_out_fence_for_connector(state->state, connector,
   fence_ptr);
+   } else if (property == connector->max_bpc_property) {
+   state->max_requested_bpc = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
   

[Intel-gfx] [PATCH v6 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp

2018-09-17 Thread Radhakrishna Sripada
Use the newly added "max bpc" connector property to limit pipe bpp.

V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
clamping of pipe bpp based on connector info

Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Cc: Kishore Kadiyala 
Cc: Manasi Navare 
Cc: Stanislav Lisovskiy 
Signed-off-by: Radhakrishna Sripada 
---
 drivers/gpu/drm/i915/intel_display.c | 49 
 drivers/gpu/drm/i915/intel_dp.c  |  5 
 drivers/gpu/drm/i915/intel_hdmi.c|  5 
 3 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index eb25037d7b38..219323f6b16e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10845,29 +10845,37 @@ static void 
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
 }
 
 static void
-connected_sink_compute_bpp(struct intel_connector *connector,
-  struct intel_crtc_state *pipe_config)
+connected_sink_max_bpp(struct drm_connector_state *conn_state,
+  struct intel_crtc_state *pipe_config)
 {
-   const struct drm_display_info *info = >base.display_info;
-   int bpp = pipe_config->pipe_bpp;
-
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
- connector->base.base.id,
- connector->base.name);
-
-   /* Don't use an invalid EDID bpc value */
-   if (info->bpc != 0 && info->bpc * 3 < bpp) {
-   DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported 
max of %d\n",
- bpp, info->bpc * 3);
-   pipe_config->pipe_bpp = info->bpc * 3;
+   if (pipe_config->pipe_bpp < conn_state->max_bpc * 3) {
+   conn_state->max_bpc = pipe_config->pipe_bpp / 3;
+   return;
}
 
-   /* Clamp bpp to 8 on screens without EDID 1.4 */
-   if (info->bpc == 0 && bpp > 24) {
-   DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit 
of 24\n",
- bpp);
-   pipe_config->pipe_bpp = 24;
+   switch (conn_state->max_bpc) {
+   case 8:
+   case 9:
+   pipe_config->pipe_bpp = 8*3;
+   break;
+   case 10:
+   case 11:
+   pipe_config->pipe_bpp = 10*3;
+   break;
+   case 12:
+   case 13:
+   case 14:
+   case 15:
+   pipe_config->pipe_bpp = 12*3;
+   break;
+   case 16:
+   pipe_config->pipe_bpp = 16*3;
+   break;
+   default:
+   break;
}
+
+   DRM_DEBUG_KMS("Limiting display bpp to %d\n", pipe_config->pipe_bpp);
 }
 
 static int
@@ -10898,8 +10906,7 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
if (connector_state->crtc != >base)
continue;
 
-   connected_sink_compute_bpp(to_intel_connector(connector),
-  pipe_config);
+   connected_sink_max_bpp(connector_state, pipe_config);
}
 
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 436c22de33b6..aefca1d9e87b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5719,6 +5719,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
intel_attach_force_audio_property(connector);
 
intel_attach_broadcast_rgb_property(connector);
+   if ((IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
+IS_CHERRYVIEW(dev_priv)))
+   drm_connector_attach_max_bpc_property(connector, 8, 10);
+   else if (INTEL_GEN(dev_priv) >= 5)
+   drm_connector_attach_max_bpc_property(connector, 8, 12);
 
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index a2dab0b6bde6..2b432c7e4f8a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2109,11 +2109,16 @@ static const struct drm_encoder_funcs 
intel_hdmi_enc_funcs = {
 static void
 intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector 
*connector)
 {
+   struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+
+   if (!HAS_GMCH_DISPLAY(dev_priv))
+

Re: [Intel-gfx] linux-firmware pull request(ICL:DMC)

2018-09-17 Thread Josh Boyer
On Mon, Sep 17, 2018 at 5:10 PM Srivatsa, Anusha
 wrote:
>
> Ping -
>
> Can we have this blob merged to linux-firmware.git please?
>
>
>
> Anusha
>
>
>
> From: Srivatsa, Anusha
> Sent: Friday, September 7, 2018 10:02 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: FW: linux-firmware pull request(ICL:DMC)
>
>
>
> Adding ML.
>
>
>
> Anusha
>
>
>
> From: Srivatsa, Anusha
> Sent: Wednesday, September 5, 2018 1:40 PM
> To: jwbo...@kernel.org; b...@decadent.org.uk; k...@kernel.org
> Subject: linux-firmware pull request(ICL:DMC)
>
>
>
> Hi Josh,Ben,Kyle,
>
>
>
> Please consider pulling the following i915 updates to linux-firmware.git.
>
> The following changes since commit 85c5d90fc155d78531efa5d2b02e92aaef7e4b88:
>
>   nvidia: switch GP10[2467] to newer scrubber/ACR firmware (from GP108) 
> (2018-09-04 09:46:41 -0400)
>
> are available in the git repository at:
>
>   git://anongit.freedesktop.org/git/drm/drm-firmware.git/ master
>
> for you to fetch changes up to 218e3171e3f9390b26535fefc9d0936ec81919fd:
>
>   Revert "linux-firmware: Add HuC v3.00.2225 for geminilake" (2018-09-05 
> 13:03:55 -0700)
>
> 
> Anusha Srivatsa (4):
>
>   firmware/icl/dmc: Add DMC v1.07 for Icelake.
>   Merge remote-tracking branch 'official/master'
>   Revert "linux-firmware: Add GuC v11.98 for geminilake"
>   Revert "linux-firmware: Add HuC v3.00.2225 for geminilake"
>
>  WHENCE   |   3 +++
>  i915/icl_dmc_ver1_07.bin | Bin 0 -> 25716 bytes
>  2 files changed, 3 insertions(+)
>  create mode 100644 i915/icl_dmc_ver1_07.bin

Is there any way to clean up the branch you're asking us to pull from?
 There are a bunch of reverts and merge commits in here that wind up
adding and removing things, referencing commits that don't actually
exist in the linux-firmware repo.

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


[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree

2018-09-17 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/i915/i915_drv.c

between commit:

  55ac5a1614f9 ("drm/i915: Attach the pci match data to the device upon 
creation")

from the drm tree and commit:

  1feb64c49d7f ("drm/i915: Clear DRIVER_ATOMIC on a per-device basis")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_drv.c
index 5dd7fc582e6f,61199defb470..
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@@ -1384,14 -1336,22 +1384,14 @@@ int i915_driver_load(struct pci_dev *pd
struct drm_i915_private *dev_priv;
int ret;
  
-   /* Enable nuclear pageflip on ILK+ */
-   if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
-   driver.driver_features &= ~DRIVER_ATOMIC;
 -  ret = -ENOMEM;
 -  dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
 -  if (dev_priv)
 -  ret = drm_dev_init(_priv->drm, , >dev);
 -  if (ret) {
 -  DRM_DEV_ERROR(>dev, "allocation failed\n");
 -  goto out_free;
 -  }
--
 -  dev_priv->drm.pdev = pdev;
 -  dev_priv->drm.dev_private = dev_priv;
 +  dev_priv = i915_driver_create(pdev, ent);
 +  if (!dev_priv)
 +  return -ENOMEM;
  
+   /* Disable nuclear pageflip by default on pre-ILK */
+   if (!i915_modparams.nuclear_pageflip && match_info->gen < 5)
+   dev_priv->drm.driver_features &= ~DRIVER_ATOMIC;
+ 
ret = pci_enable_device(pdev);
if (ret)
goto out_fini;


pgpwybu9WMtw_.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/psr: Enable PSR1 on gen-9+ HW

2018-09-17 Thread Dhinakaran Pandiyan
On Tue, 2018-09-11 at 17:04 +0300, Ville Syrjälä wrote:
> On Thu, Sep 06, 2018 at 10:06:09PM -0700, Rodrigo Vivi wrote:
> > On Thu, Sep 06, 2018 at 04:52:02PM -0700, Dhinakaran Pandiyan
> > wrote:
> > > We have new tests and fixes in place since the feature was last
> > > disabled.
> > > 
> > > Try again for gen-9+ hardware and enable only PSR1 as a first
> > > step.
> > > 
> > > Cc: Jani Nikula 
> > > Cc: Jose Roberto de Souza 
> > > Cc: Paulo Zanoni 
> > > Cc: Rodrigo Vivi 
> > > Cc: Ville Syrjälä 
> > > References: commit 2ee7dc497e34 ("drm/i915: disable PSR by
> > > default on HSW/BDW")
> > > References: commit dcb2e993f3c0 ("Revert "drm/i915: Enable PSR by
> > > default on Valleyview and Cherryview."")
> > > Signed-off-by: Dhinakaran Pandiyan  > > >
> > > ---
> > >  drivers/gpu/drm/i915/intel_psr.c | 17 -
> > >  1 file changed, 8 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > b/drivers/gpu/drm/i915/intel_psr.c
> > > index b6838b525502..fc823f93a4dc 100644
> > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > @@ -71,6 +71,10 @@ static bool psr_global_enabled(u32 debug)
> > >  static bool intel_psr2_enabled(struct drm_i915_private
> > > *dev_priv,
> > >  const struct intel_crtc_state
> > > *crtc_state)
> > >  {
> > > + /* Disable PSR2 by default for all platforms */
> > > + if (i915_modparams.enable_psr == -1)
> > > + return false;
> > > +
> > >   switch (dev_priv->psr.debug & I915_PSR_DEBUG_MODE_MASK)
> > > {
> > >   case I915_PSR_DEBUG_FORCE_PSR1:
> > >   return false;
> > > @@ -1051,7 +1055,7 @@ void intel_psr_flush(struct
> > > drm_i915_private *dev_priv,
> > >   * intel_psr_init - Init basic PSR work and mutex.
> > >   * @dev_priv: i915 device private
> > >   *
> > > - * This function is  called only once at driver load to
> > > initialize basic
> > > + * This function is called only once at driver load to
> > > initialize basic
> > >   * PSR stuff.
> > >   */
> > >  void intel_psr_init(struct drm_i915_private *dev_priv)
> > > @@ -1065,19 +1069,14 @@ void intel_psr_init(struct
> > > drm_i915_private *dev_priv)
> > >   if (!dev_priv->psr.sink_support)
> > >   return;
> > >  
> > > - if (i915_modparams.enable_psr == -1) {
> > > - i915_modparams.enable_psr = dev_priv-
> > > >vbt.psr.enable;
> > > -
> > > - /* Per platform default: all disabled. */
> > > - i915_modparams.enable_psr = 0;
> > > - }
> > > + if (i915_modparams.enable_psr == -1)
> > > + if (INTEL_GEN(dev_priv) < 9 || !dev_priv-
> > > >vbt.psr.enable)
> > > + i915_modparams.enable_psr = 0;
> > >  
> > > - /* Set link_standby x link_off defaults */
> > >   if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
> > >   /* HSW and BDW require workarounds that we don't
> > > implement. */
> > >   dev_priv->psr.link_standby = false;
> > >   else
> > > - /* For new platforms let's respect VBT back
> > > again */
> > 
> > bikeshed: Can we please leave the clean-up for a separated patch?
> > In case we need to revert we don't loose the clean-up part! :$
> > 
> > Also a bikeshed of bikeshed: I think we need to revisit this block
> > entirely
> > anyways. I can't remember why we stopped respecting the bspec here.
> > And probably this was only masking some issues that got fixed
> > during
> > your great journey! ;)
> 
> Another vbt related thing was the aux handshake thing. We tried it
> here
> https://patchwork.freedesktop.org/series/8046/ but IIRC it caused
> some
> problems that no one had time to diagnose so we never merged that
> stuff.
> Not sure if anyone wants to try and figure out what went wrong there.
> 
I had to check with Art about this; we do need AUX handshake to wake up
the sink like the spec says. The current code is right.

> Actually, after a bit more digging I guess the fails were listed here
> https://lists.freedesktop.org/archives/intel-gfx/2016-June/097379.htm
> l
> Some sink crc issues, but as that was deemed unusable anyway maybe
> there was nothing wrong after all?
Sink crc issues should not been seen anymore.

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


[Intel-gfx] [PATCH xf86-video-intel] sna/io: Align the linear source buffer to cache line for 2d source copy

2018-09-17 Thread Guang Bai
On BDW+ the linear source buffer of 2d source copy needs to start from
cache line boundary based on hardware design. Apply this alignment policy
to all platforms accordingly.

v2: Apply these changes only to SKL+ for not breaking old platforms
based on code review (Chris).

v3: Apply these changes for BDW+ onward chipsets based on hardware
design teams' inputs.

Cc: Chris Wilson 
Signed-off-by: Guang Bai 
---
 src/sna/sna_io.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/sna/sna_io.c b/src/sna/sna_io.c
index d32bd58..35b90e5 100644
--- a/src/sna/sna_io.c
+++ b/src/sna/sna_io.c
@@ -1077,12 +1077,16 @@ tile:
 
/* Count the total number of bytes to be read and 
allocate a
 * single buffer large enough. Or if it is very small, 
combine
-* with other allocations. */
+* with other allocations. Each sub-buffer starting 
point
+* (offset) should be aligned to 64-byte cache line 
boundary
+* for BDW+ according to hardware design specifications.
+*/
offset = 0;
for (n = 0; n < nbox_this_time; n++) {
int height = box[n].y2 - box[n].y1;
int width = box[n].x2 - box[n].x1;
offset += PITCH(width, 
dst->drawable.bitsPerPixel >> 3) * height;
+   offset = ALIGN(offset, 64);
}
 
src_bo = kgem_create_buffer(kgem, offset,
@@ -1143,6 +1147,7 @@ tile:
 
box++;
offset += pitch * height;
+   offset = ALIGN(offset, 64);
} while (--nbox_this_time);
assert(offset == __kgem_buffer_size(src_bo));
sigtrap_put();
-- 
2.7.4

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


[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS

2018-09-17 Thread Patchwork
== Series Details ==

Series: drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not 
support KMS
URL   : https://patchwork.freedesktop.org/series/49816/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4834_full -> Patchwork_10207_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_10207_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_10207_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_10207_full:

  === IGT changes ===

 Warnings 

igt@pm_rc6_residency@rc6-accuracy:
  shard-snb:  SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_10207_full that come from known 
issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_big:
  shard-hsw:  PASS -> TIMEOUT (fdo#107937)

igt@kms_busy@extended-modeset-hang-newfb-render-b:
  shard-glk:  NOTRUN -> DMESG-WARN (fdo#107956)

igt@kms_cursor_legacy@pipe-b-torture-bo:
  shard-glk:  PASS -> INCOMPLETE (k.org#198133, fdo#103359)

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#105363)

igt@kms_flip@dpms-vs-vblank-race-interruptible:
  shard-glk:  PASS -> FAIL (fdo#103060)

igt@kms_flip@flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#102887, fdo#105363)


 Possible fixes 

igt@gem_exec_schedule@preempt-contexts-render:
  shard-snb:  INCOMPLETE (fdo#105411) -> SKIP

igt@kms_atomic_transition@plane-all-modeset-transition:
  shard-glk:  INCOMPLETE (k.org#198133, fdo#103359) -> PASS

igt@kms_frontbuffer_tracking@fbc-2p-indfb-fliptrack:
  shard-glk:  FAIL (fdo#103167) -> PASS


  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#107937 https://bugs.freedesktop.org/show_bug.cgi?id=107937
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4834 -> Patchwork_10207

  CI_DRM_4834: e13c7f93395b309bc440805cb7ee957c63324fa0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4645: 03b90a39ed12a568c9da752466ea708d6348e110 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10207: d576890f0facb93320df622de6ee3c2cb7841099 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS

2018-09-17 Thread Patchwork
== Series Details ==

Series: drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not 
support KMS
URL   : https://patchwork.freedesktop.org/series/49816/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4834 -> Patchwork_10207 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_10207 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_10207, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/49816/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_10207:

  === IGT changes ===

 Warnings 

igt@pm_rpm@module-reload:
  fi-hsw-4770r:   SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_10207 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_guc:
  fi-skl-guc: NOTRUN -> DMESG-WARN (fdo#107258)

igt@gem_exec_suspend@basic-s4-devices:
  fi-blb-e6850:   PASS -> INCOMPLETE (fdo#107718)

igt@kms_psr@primary_page_flip:
  fi-icl-u:   PASS -> FAIL (fdo#107336)


 Possible fixes 

igt@drv_module_reload@basic-reload-inject:
  fi-hsw-4770r:   DMESG-WARN (fdo#107924, fdo#107425) -> PASS

igt@kms_psr@primary_page_flip:
  fi-kbl-r:   FAIL (fdo#107336) -> PASS


  fdo#107258 https://bugs.freedesktop.org/show_bug.cgi?id=107258
  fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
  fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
  fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
  fdo#107924 https://bugs.freedesktop.org/show_bug.cgi?id=107924


== Participating hosts (47 -> 40) ==

  Additional (1): fi-skl-guc 
  Missing(8): fi-ilk-m540 fi-skl-gvtdvm fi-hsw-4200u fi-bdw-gvtdvm 
fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper 


== Build changes ==

* Linux: CI_DRM_4834 -> Patchwork_10207

  CI_DRM_4834: e13c7f93395b309bc440805cb7ee957c63324fa0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4645: 03b90a39ed12a568c9da752466ea708d6348e110 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10207: d576890f0facb93320df622de6ee3c2cb7841099 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d576890f0fac drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not 
support KMS

== Logs ==

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


Re: [Intel-gfx] [PATCH v2 1/6] drm/i915/runtime_pm: Share code to enable/disable PCH reset handshake

2018-09-17 Thread Souza, Jose
On Fri, 2018-09-14 at 08:37 -0700, Rodrigo Vivi wrote:
> On Fri, Sep 14, 2018 at 05:52:39PM +0300, Ville Syrjälä wrote:
> > On Fri, Sep 14, 2018 at 07:18:44AM -0700, José Roberto de Souza
> > wrote:
> > > Instead of have the same code spread into 4 platforms lets share
> > > it.
> > > BXT do not have a PCH so here also handling this case by unseting
> > > RESET_PCH_HANDSHAKE_ENABLE.
> > > 
> > > v2(Rodrigo):
> > > - renamed to intel_pch_reset_handshake()
> > > - added comment about why BXT need the bit to be unset
> > > 
> > > Cc: Rodrigo Vivi 
> > > Signed-off-by: José Roberto de Souza 
> > > ---
> > >  drivers/gpu/drm/i915/intel_runtime_pm.c | 36 ---
> > > --
> > >  1 file changed, 17 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index 9bebec389de1..1bcd0e51fca1 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -3239,18 +3239,29 @@ static void icl_mbus_init(struct
> > > drm_i915_private *dev_priv)
> > >   I915_WRITE(MBUS_ABOX_CTL, val);
> > >  }
> > >  
> > > +static void intel_pch_reset_handshake(struct drm_i915_private
> > > *dev_priv)
> > > +{
> > > + u32 val = I915_READ(HSW_NDE_RSTWRN_OPT);
> > > +
> > > + /* BXT don't have PCH and it requires that this bit is always
> > > unset */
> > > + if (HAS_PCH_SPLIT(dev_priv))
> > 
> > Still would prefer 'bool enable' etc. rather than this magic
> > inside.
> 
> I agree. So we could keep the original BXT comment where it is...

Several other places also uses HAS_PCH_SPLIT() to differentiate BXT of
other platforms so it is not something new, also adding the 'bool
enable' would move part of the "magic" to the callers as we need to
check if HAS_PCH_NOP(dev_priv) is true in the next patch and unset the
handshake.

> 
> > 
> > > + val |= RESET_PCH_HANDSHAKE_ENABLE;
> > > + else
> > > + val &= ~RESET_PCH_HANDSHAKE_ENABLE;
> > > +
> > > + I915_WRITE(HSW_NDE_RSTWRN_OPT, val);
> > > +}
> > > +
> > >  static void skl_display_core_init(struct drm_i915_private
> > > *dev_priv,
> > >  bool resume)
> > >  {
> > >   struct i915_power_domains *power_domains = _priv-
> > > >power_domains;
> > >   struct i915_power_well *well;
> > > - uint32_t val;
> > >  
> > >   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> > >  
> > >   /* enable PCH reset handshake */
> > > - val = I915_READ(HSW_NDE_RSTWRN_OPT);
> > > - I915_WRITE(HSW_NDE_RSTWRN_OPT, val |
> > > RESET_PCH_HANDSHAKE_ENABLE);
> > > + intel_pch_reset_handshake(dev_priv);
> > >  
> > >   /* enable PG1 and Misc I/O */
> > >   mutex_lock(_domains->lock);
> > > @@ -3306,19 +3317,10 @@ void bxt_display_core_init(struct
> > > drm_i915_private *dev_priv,
> > >  {
> > >   struct i915_power_domains *power_domains = _priv-
> > > >power_domains;
> > >   struct i915_power_well *well;
> > > - uint32_t val;
> > >  
> > >   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> > >  
> > > - /*
> > > -  * NDE_RSTWRN_OPT RST PCH Handshake En must always be 0b on BXT
> > > -  * or else the reset will hang because there is no PCH to
> > > respond.
> > > -  * Move the handshake programming to initialization sequence.
> > > -  * Previously was left up to BIOS.
> > > -  */
> > > - val = I915_READ(HSW_NDE_RSTWRN_OPT);
> > > - val &= ~RESET_PCH_HANDSHAKE_ENABLE;
> > > - I915_WRITE(HSW_NDE_RSTWRN_OPT, val);
> > > + intel_pch_reset_handshake(dev_priv);
> > >  
> > >   /* Enable PG1 */
> > >   mutex_lock(_domains->lock);
> > > @@ -3439,9 +3441,7 @@ static void cnl_display_core_init(struct
> > > drm_i915_private *dev_priv, bool resume
> > >   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> > >  
> > >   /* 1. Enable PCH Reset Handshake */
> > > - val = I915_READ(HSW_NDE_RSTWRN_OPT);
> > > - val |= RESET_PCH_HANDSHAKE_ENABLE;
> > > - I915_WRITE(HSW_NDE_RSTWRN_OPT, val);
> > > + intel_pch_reset_handshake(dev_priv);
> > >  
> > >   /* 2. Enable Comp */
> > >   val = I915_READ(CHICKEN_MISC_2);
> > > @@ -3524,9 +3524,7 @@ static void icl_display_core_init(struct
> > > drm_i915_private *dev_priv,
> > >   gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
> > >  
> > >   /* 1. Enable PCH reset handshake. */
> > > - val = I915_READ(HSW_NDE_RSTWRN_OPT);
> > > - val |= RESET_PCH_HANDSHAKE_ENABLE;
> > > - I915_WRITE(HSW_NDE_RSTWRN_OPT, val);
> > > + intel_pch_reset_handshake(dev_priv);
> > >  
> > >   for (port = PORT_A; port <= PORT_B; port++) {
> > >   /* 2. Enable DDI combo PHY comp. */
> > > -- 
> > > 2.19.0
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrjälä
> > Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2] drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS

2018-09-17 Thread José Roberto de Souza
All DRM_CLIENT capabilities are tied to KMS support, so returning
-EOPNOTSUPP when KMS is not supported.

v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
in uapi) instead of -ENOTSUPP

Cc: Chris Wilson 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/drm_ioctl.c  | 3 +++
 drivers/gpu/drm/i915/i915_perf.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 60dfbfae6a02..c0de628c194c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
 {
struct drm_set_client_cap *req = data;
 
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EOPNOTSUPP;
+
switch (req->capability) {
case DRM_CLIENT_CAP_STEREO_3D:
if (req->value > 1)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 664b96bb65a3..c1edd1e69a3e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2817,7 +2817,7 @@ int i915_perf_open_ioctl(struct drm_device *dev, void 
*data,
 
if (!dev_priv->perf.initialized) {
DRM_DEBUG("i915 perf interface not available for this 
system\n");
-   return -ENOTSUPP;
+   return -EOPNOTSUPP;
}
 
known_open_flags = I915_PERF_FLAG_FD_CLOEXEC |
-- 
2.19.0

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


Re: [Intel-gfx] linux-firmware pull request(ICL:DMC)

2018-09-17 Thread Srivatsa, Anusha
Ping -
Can we have this blob merged to linux-firmware.git please?

Anusha

From: Srivatsa, Anusha
Sent: Friday, September 7, 2018 10:02 AM
To: intel-gfx@lists.freedesktop.org
Subject: FW: linux-firmware pull request(ICL:DMC)

Adding ML.

Anusha

From: Srivatsa, Anusha
Sent: Wednesday, September 5, 2018 1:40 PM
To: jwbo...@kernel.org; 
b...@decadent.org.uk; 
k...@kernel.org
Subject: linux-firmware pull request(ICL:DMC)


Hi Josh,Ben,Kyle,



Please consider pulling the following i915 updates to linux-firmware.git.

The following changes since commit 85c5d90fc155d78531efa5d2b02e92aaef7e4b88:

  nvidia: switch GP10[2467] to newer scrubber/ACR firmware (from GP108) 
(2018-09-04 09:46:41 -0400)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm/drm-firmware.git/ master

for you to fetch changes up to 218e3171e3f9390b26535fefc9d0936ec81919fd:

  Revert "linux-firmware: Add HuC v3.00.2225 for geminilake" (2018-09-05 
13:03:55 -0700)


Anusha Srivatsa (4):

  firmware/icl/dmc: Add DMC v1.07 for Icelake.
  Merge remote-tracking branch 'official/master'
  Revert "linux-firmware: Add GuC v11.98 for geminilake"
  Revert "linux-firmware: Add HuC v3.00.2225 for geminilake"

 WHENCE   |   3 +++
 i915/icl_dmc_ver1_07.bin | Bin 0 -> 25716 bytes
 2 files changed, 3 insertions(+)
 create mode 100644 i915/icl_dmc_ver1_07.bin

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


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace some PAGE_SHIFTs with I915_GTT_PAGE_SIZE

2018-09-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Replace some PAGE_SHIFTs with I915_GTT_PAGE_SIZE
URL   : https://patchwork.freedesktop.org/series/49801/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4834_full -> Patchwork_10206_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

  Here are the changes found in Patchwork_10206_full that come from known 
issues:

  === IGT changes ===

 Issues hit 

igt@drv_suspend@shrink:
  shard-apl:  PASS -> INCOMPLETE (fdo#103927, fdo#106886)

igt@kms_busy@extended-modeset-hang-newfb-render-b:
  shard-glk:  NOTRUN -> DMESG-WARN (fdo#107956)


 Possible fixes 

igt@gem_exec_schedule@preempt-contexts-render:
  shard-snb:  INCOMPLETE (fdo#105411) -> SKIP

igt@kms_atomic_transition@plane-all-modeset-transition:
  shard-glk:  INCOMPLETE (fdo#103359, k.org#198133) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS


  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4834 -> Patchwork_10206

  CI_DRM_4834: e13c7f93395b309bc440805cb7ee957c63324fa0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4645: 03b90a39ed12a568c9da752466ea708d6348e110 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10206: 3ef2392b50ed1115de31409adc4f6a768dbe4965 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10206/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/icl: Enable DC9 as lowest possible state during screen-off

2018-09-17 Thread Srivatsa, Anusha


>-Original Message-
>From: Vivi, Rodrigo
>Sent: Thursday, September 13, 2018 1:14 PM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org; Manna, Animesh
>; Deak, Imre ; Ausmus,
>James 
>Subject: Re: [PATCH] drm/i915/icl: Enable DC9 as lowest possible state during
>screen-off
>
>On Thu, Sep 13, 2018 at 12:31:09PM -0700, Anusha Srivatsa wrote:
>> From: Animesh Manna 
>>
>> ICL supports DC5, DC6, and DC9. Enable DC9 during screen-off, and
>> enable
>> DC5/6 when appropriate.
>>
>> v2: (James Ausmus)
>>  - Also handle ICL as GEN9_LP in i915_drm_suspend_late and
>>i915_drm_suspend_early
>>  - Add DC9 to gen9_dc_mask for ICL
>>  - Re-order GEN checks for newest platform first
>>  - Use INTEL_GEN instead of INTEL_INFO->gen
>>  - Use INTEL_GEN >= 11 instead of IS_ICELAKE
>>  - Consolidate GEN checks
>>
>> v3: (James Ausmus)
>>  - Also allow DC6 for ICL (Imre, Art)
>>  - Simplify !(GEN >= 11) to GEN < 11 (Imre)
>>
>> v4: (James Ausmus)
>>  - Don't call intel_power_sequencer_reset after DC9 for Gen11+, as the
>>PPS regs are Always On
>>  - Rebase against upstream changes
>>
>> v5: (Anusha Srivatsa)
>> - rebased against the latest upstream changes.
>
>First concern with this patch is regarding the tests...
>How is this getting tested? Are you able to see DC6 and DC9?
>
>>
>> Cc: Imre Deak 
>> Cc: Rodrigo Vivi 
>> Signed-off-by: Animesh Manna 
>> Signed-off-by: James Ausmus 
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.c | 20 ++---
>>  drivers/gpu/drm/i915/intel_drv.h|  3 +++
>>  drivers/gpu/drm/i915/intel_runtime_pm.c | 29
>> +++--
>>  3 files changed, 37 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c index 2ddf8538cb47..86a83e0a7ef2
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -1855,7 +1855,7 @@ static int i915_drm_resume_early(struct
>> drm_device *dev)
>>
>>  intel_uncore_resume_early(dev_priv);
>>
>> -if (IS_GEN9_LP(dev_priv)) {
>> +if (INTEL_GEN(dev_priv) >= 11 || IS_GEN9_LP(dev_priv)) {
>>  gen9_sanitize_dc_state(dev_priv);
>>  bxt_disable_dc9(dev_priv);
>>  } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) { @@
>> -2622,7 +2622,10 @@ static int intel_runtime_suspend(struct device *kdev)
>>  intel_uncore_suspend(dev_priv);
>>
>>  ret = 0;
>> -if (IS_GEN9_LP(dev_priv)) {
>> +if (IS_ICELAKE(dev_priv)) {
>> +icl_display_core_uninit(dev_priv);
>> +bxt_enable_dc9(dev_priv);
>> +} else if (IS_GEN9_LP(dev_priv)) {
>>  bxt_display_core_uninit(dev_priv);
>>  bxt_enable_dc9(dev_priv);
>>  } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) { @@
>> -2707,7 +2710,18 @@ static int intel_runtime_resume(struct device *kdev)
>>  if (intel_uncore_unclaimed_mmio(dev_priv))
>>  DRM_DEBUG_DRIVER("Unclaimed access during suspend,
>bios?\n");
>>
>> -if (IS_GEN9_LP(dev_priv)) {
>> +if (IS_ICELAKE(dev_priv)) {
>
>commit message mention the use of INTEL_GEN instead of ICELAKE, but it seems
>we are missing some replacements here
Actually double checked with the internal version of this patch, seems like 
IS_ICELAKE was what was used in the code...

Maybe change the commit log?

>
>> +bxt_disable_dc9(dev_priv);
>> +icl_display_core_init(dev_priv, true);
>> +if (dev_priv->csr.dmc_payload) {
>> +if (dev_priv->csr.allowed_dc_mask &
>> +DC_STATE_EN_UPTO_DC6)
>> +skl_enable_dc6(dev_priv);
>> +else if (dev_priv->csr.allowed_dc_mask &
>> + DC_STATE_EN_UPTO_DC5)
>> +gen9_enable_dc5(dev_priv);
>> +}
>> +} else if (IS_GEN9_LP(dev_priv)) {
>>  bxt_disable_dc9(dev_priv);
>>  bxt_display_core_init(dev_priv, true);
>>  if (dev_priv->csr.dmc_payload &&
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index bf1c38728a59..f0385fe5bb15 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1627,6 +1627,7 @@ void bxt_enable_dc9(struct drm_i915_private
>> *dev_priv);  void bxt_disable_dc9(struct drm_i915_private *dev_priv);
>> void gen9_enable_dc5(struct drm_i915_private *dev_priv);  unsigned int
>> skl_cdclk_get_vco(unsigned int freq);
>> +void skl_enable_dc6(struct drm_i915_private *dev_priv);
>>  void intel_dp_get_m_n(struct intel_crtc *crtc,
>>struct intel_crtc_state *pipe_config);  void
>> intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n); @@
>> -1966,6 +1967,8 @@ int intel_power_domains_init(struct
>> drm_i915_private *);  void intel_power_domains_cleanup(struct
>> drm_i915_private *dev_priv);  void 

Re: [Intel-gfx] [PATCH] [intel-gfx] drm/i915/csr Added DC5 and DC6 counter register for ICL in debugfs entry.

2018-09-17 Thread kbuild test robot
Hi Jyoti,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.19-rc4 next-20180913]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jyoti-Yadav/drm-i915-csr-Added-DC5-and-DC6-counter-register-for-ICL-in-debugfs-entry/20180918-012350
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x077-201837 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:9,
from include/linux/wait.h:7,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/linux/debugfs.h:15,
from drivers/gpu//drm/i915/i915_debugfs.c:29:
   drivers/gpu//drm/i915/i915_debugfs.c: In function 'i915_dmc_info':
   drivers/gpu//drm/i915/i915_debugfs.c:2884:28: error: called object is not a 
function or function pointer
 (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))
 ~~^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu//drm/i915/i915_debugfs.c:2883:2: note: in expansion of macro 'if'
 if (IS_KABYLAKE(dev_priv) ||
 ^~
   drivers/gpu//drm/i915/i915_debugfs.c:2884:28: error: called object is not a 
function or function pointer
 (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))
 ~~^
   include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu//drm/i915/i915_debugfs.c:2883:2: note: in expansion of macro 'if'
 if (IS_KABYLAKE(dev_priv) ||
 ^~
   drivers/gpu//drm/i915/i915_debugfs.c:2884:28: error: called object is not a 
function or function pointer
 (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))
 ~~^
   include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> drivers/gpu//drm/i915/i915_debugfs.c:2883:2: note: in expansion of macro 'if'
 if (IS_KABYLAKE(dev_priv) ||
 ^~

vim +/if +2883 drivers/gpu//drm/i915/i915_debugfs.c

1da51581 Imre Deak2013-11-25  2861  
b7cec66d Damien Lespiau   2015-10-27  2862  static int i915_dmc_info(struct 
seq_file *m, void *unused)
b7cec66d Damien Lespiau   2015-10-27  2863  {
36cdd013 David Weinehall  2016-08-22  2864  struct drm_i915_private 
*dev_priv = node_to_i915(m->private);
b7cec66d Damien Lespiau   2015-10-27  2865  struct intel_csr *csr;
b7cec66d Damien Lespiau   2015-10-27  2866  
ab309a6a Michal Wajdeczko 2017-12-15  2867  if (!HAS_CSR(dev_priv))
ab309a6a Michal Wajdeczko 2017-12-15  2868  return -ENODEV;
b7cec66d Damien Lespiau   2015-10-27  2869  
b7cec66d Damien Lespiau   2015-10-27  2870  csr = _priv->csr;
b7cec66d Damien Lespiau   2015-10-27  2871  
6fb403de Mika Kuoppala2015-10-30  2872  intel_runtime_pm_get(dev_priv);
6fb403de Mika Kuoppala2015-10-30  2873  
b7cec66d Damien Lespiau   2015-10-27  2874  seq_printf(m, "fw loaded: 
%s\n", yesno(csr->dmc_payload != NULL));
b7cec66d Damien Lespiau   2015-10-27  2875  seq_printf(m, "path: %s\n", 
csr->fw_path);
b7cec66d Damien Lespiau   2015-10-27  2876  
b7cec66d Damien Lespiau   2015-10-27  2877  if (!csr->dmc_payload)
6fb403de Mika Kuoppala2015-10-30  2878  goto out;
b7cec66d Damien Lespiau   2015-10-27  2879  
b7cec66d Damien Lespiau   2015-10-27  2880  seq_printf(m, "version: 
%d.%d\n", CSR_VERSION_MAJOR(csr->version),
b7cec66d Damien Lespiau   2015-10-27  2881 
CSR_VERSION_MINOR(csr->version));
b7cec66d Damien Lespiau   2015-10-27  2882  
48de568c Mika Kuoppala2017-05-09 @2883  if (IS_KABYLAKE(dev_priv) ||
71660c92 Jyoti Yadav  2018-09-17  2884  (IS_SKYLAKE(dev_priv) && 
csr->version >= CSR_VERSION(1, 6))
71660c92 Jyoti Yadav  2018-09-17  2885  (IS_ICELAKE(dev_priv) 
&& csr->version >= CSR_VERSION(1, 7))) {
8337206d Damien Lespiau   2015-10-30  2886  seq_printf(m, "DC3 -> 
DC5 count: %d\n",
8337206d Damien Lespiau   2015-10-30  2887 
I915_READ(SKL_CSR_DC3_DC5_COUNT));
8337206d Damien Lespiau   2015-10-30  2888  seq_printf(m, "DC5 -> 
DC6 count: %d\n",
8337206d Damien Lespiau   2015-10-30  

Re: [Intel-gfx] [PATCH] [intel-gfx] drm/i915/csr Added DC5 and DC6 counter register for ICL in debugfs entry.

2018-09-17 Thread kbuild test robot
Hi Jyoti,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.19-rc4 next-20180913]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jyoti-Yadav/drm-i915-csr-Added-DC5-and-DC6-counter-register-for-ICL-in-debugfs-entry/20180918-012350
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-x005-201837 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu//drm/i915/i915_debugfs.c: In function 'i915_dmc_info':
>> drivers/gpu//drm/i915/i915_debugfs.c:2884:28: error: called object is not a 
>> function or function pointer
 (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))
 ~~^

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

  2861  
  2862  static int i915_dmc_info(struct seq_file *m, void *unused)
  2863  {
  2864  struct drm_i915_private *dev_priv = node_to_i915(m->private);
  2865  struct intel_csr *csr;
  2866  
  2867  if (!HAS_CSR(dev_priv))
  2868  return -ENODEV;
  2869  
  2870  csr = _priv->csr;
  2871  
  2872  intel_runtime_pm_get(dev_priv);
  2873  
  2874  seq_printf(m, "fw loaded: %s\n", yesno(csr->dmc_payload != 
NULL));
  2875  seq_printf(m, "path: %s\n", csr->fw_path);
  2876  
  2877  if (!csr->dmc_payload)
  2878  goto out;
  2879  
  2880  seq_printf(m, "version: %d.%d\n", 
CSR_VERSION_MAJOR(csr->version),
  2881 CSR_VERSION_MINOR(csr->version));
  2882  
  2883  if (IS_KABYLAKE(dev_priv) ||
> 2884  (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))
  2885  (IS_ICELAKE(dev_priv) && csr->version >= CSR_VERSION(1, 
7))) {
  2886  seq_printf(m, "DC3 -> DC5 count: %d\n",
  2887 I915_READ(SKL_CSR_DC3_DC5_COUNT));
  2888  seq_printf(m, "DC5 -> DC6 count: %d\n",
  2889 I915_READ(SKL_CSR_DC5_DC6_COUNT));
  2890  } else if (IS_BROXTON(dev_priv) && csr->version >= 
CSR_VERSION(1, 4)) {
  2891  seq_printf(m, "DC3 -> DC5 count: %d\n",
  2892 I915_READ(BXT_CSR_DC3_DC5_COUNT));
  2893  }
  2894  
  2895  out:
  2896  seq_printf(m, "program base: 0x%08x\n", 
I915_READ(CSR_PROGRAM(0)));
  2897  seq_printf(m, "ssp base: 0x%08x\n", I915_READ(CSR_SSP_BASE));
  2898  seq_printf(m, "htp: 0x%08x\n", I915_READ(CSR_HTP_SKL));
  2899  
  2900  intel_runtime_pm_put(dev_priv);
  2901  
  2902  return 0;
  2903  }
  2904  

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


.config.gz
Description: application/gzip
___
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: Replace some PAGE_SHIFTs with I915_GTT_PAGE_SIZE

2018-09-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Replace some PAGE_SHIFTs with I915_GTT_PAGE_SIZE
URL   : https://patchwork.freedesktop.org/series/49801/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4834 -> Patchwork_10206 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_10206 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_10206, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/49801/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_10206:

  === IGT changes ===

 Warnings 

igt@pm_rpm@module-reload:
  fi-hsw-4770r:   SKIP -> PASS


== Known issues ==

  Here are the changes found in Patchwork_10206 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_guc:
  fi-skl-guc: NOTRUN -> DMESG-WARN (fdo#107258)

igt@kms_chamelium@dp-edid-read:
  fi-kbl-7500u:   PASS -> FAIL (fdo#103841)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191)


 Possible fixes 

igt@drv_module_reload@basic-reload-inject:
  fi-hsw-4770r:   DMESG-WARN (fdo#107924, fdo#107425) -> PASS

igt@kms_frontbuffer_tracking@basic:
  fi-byt-clapper: FAIL (fdo#103167) -> PASS

igt@kms_psr@primary_page_flip:
  fi-kbl-r:   FAIL (fdo#107336) -> PASS


  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#107258 https://bugs.freedesktop.org/show_bug.cgi?id=107258
  fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425
  fdo#107924 https://bugs.freedesktop.org/show_bug.cgi?id=107924


== Participating hosts (47 -> 42) ==

  Additional (1): fi-skl-guc 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan 
fi-snb-2520m fi-ctg-p8600 


== Build changes ==

* Linux: CI_DRM_4834 -> Patchwork_10206

  CI_DRM_4834: e13c7f93395b309bc440805cb7ee957c63324fa0 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4645: 03b90a39ed12a568c9da752466ea708d6348e110 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10206: 3ef2392b50ed1115de31409adc4f6a768dbe4965 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

3ef2392b50ed drm/i915: Replace some PAGE_SHIFTs with I915_GTT_PAGE_SIZE

== Logs ==

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915/sdvo: Fix multi function encoder stuff

2018-09-17 Thread Ville Syrjälä
On Mon, Sep 17, 2018 at 10:16:05AM -0700, Rodrigo Vivi wrote:
> On Mon, Sep 17, 2018 at 06:15:03PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > SDVO encoders can have multiple different types of outputs hanging off
> > them. Currently the code tries to muck around with various is_foo
> > flags in the encoder to figure out which type its driving. That doesn't
> > work with atomic and other stuff, so let's nuke those flags and just
> > look at which type of connector we're actually dealing with.
> > 
> > The is_hdmi we'll need as that's not discoverable via the output flags,
> > but we'll just move it under the connector.
> > 
> > We'll also move the sdvo fixed mode handling out from the .get_modes()
> > hook into the sdvo lvds init function so that we can bail out properly
> > if there is no fixed mode to be found.
> 
> I wondered if this last part didn't deserved a separated patch. But not sure
> how chicken-egg issue this could cause so maybe the same patch is better
> indeed...

There are both chickens and eggs in there for sure. I suppose it might
have been possible to handle it by clearing the LVDS bit from
output_flag if we fail to find the mode. But then we'd be left with
an LVDS connector without the flag and I'm not quite sure where the
code would lead if we ever tried to use it. Although one can argue
that the current code already has that same issue, maybe.

> 
> Reviewed-by: Rodrigo Vivi 
> 
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_sdvo.c | 101 
> > +-
> >  1 file changed, 44 insertions(+), 57 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> > b/drivers/gpu/drm/i915/intel_sdvo.c
> > index 812fe7b06f87..701372e512a8 100644
> > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > @@ -99,31 +99,12 @@ struct intel_sdvo {
> >  */
> > uint16_t hotplug_active;
> >  
> > -   /**
> > -* This is set if we're going to treat the device as TV-out.
> > -*
> > -* While we have these nice friendly flags for output types that ought
> > -* to decide this for us, the S-Video output on our HDMI+S-Video card
> > -* shows up as RGB1 (VGA).
> > -*/
> > -   bool is_tv;
> > -
> > enum port port;
> >  
> > -   /**
> > -* This is set if we treat the device as HDMI, instead of DVI.
> > -*/
> > -   bool is_hdmi;
> > bool has_hdmi_monitor;
> > bool has_hdmi_audio;
> > bool rgb_quant_range_selectable;
> >  
> > -   /**
> > -* This is set if we detect output of sdvo device as LVDS and
> > -* have a valid fixed mode to use with the panel.
> > -*/
> > -   bool is_lvds;
> > -
> > /**
> >  * This is sdvo fixed pannel mode pointer
> >  */
> > @@ -172,6 +153,11 @@ struct intel_sdvo_connector {
> >  
> > /* this is to get the range of margin.*/
> > u32 max_hscan, max_vscan;
> > +
> > +   /**
> > +* This is set if we treat the device as HDMI, instead of DVI.
> > +*/
> > +   bool is_hdmi;
> >  };
> >  
> >  struct intel_sdvo_connector_state {
> > @@ -766,6 +752,7 @@ static bool intel_sdvo_get_input_timing(struct 
> > intel_sdvo *intel_sdvo,
> >  
> >  static bool
> >  intel_sdvo_create_preferred_input_timing(struct intel_sdvo *intel_sdvo,
> > +struct intel_sdvo_connector 
> > *intel_sdvo_connector,
> >  uint16_t clock,
> >  uint16_t width,
> >  uint16_t height)
> > @@ -778,7 +765,7 @@ intel_sdvo_create_preferred_input_timing(struct 
> > intel_sdvo *intel_sdvo,
> > args.height = height;
> > args.interlace = 0;
> >  
> > -   if (intel_sdvo->is_lvds &&
> > +   if (IS_LVDS(intel_sdvo_connector) &&
> >(intel_sdvo->sdvo_lvds_fixed_mode->hdisplay != width ||
> > intel_sdvo->sdvo_lvds_fixed_mode->vdisplay != height))
> > args.scaled = 1;
> > @@ -1067,6 +1054,7 @@ intel_sdvo_set_output_timings_from_mode(struct 
> > intel_sdvo *intel_sdvo,
> >   */
> >  static bool
> >  intel_sdvo_get_preferred_input_mode(struct intel_sdvo *intel_sdvo,
> > +   struct intel_sdvo_connector 
> > *intel_sdvo_connector,
> > const struct drm_display_mode *mode,
> > struct drm_display_mode *adjusted_mode)
> >  {
> > @@ -1077,6 +1065,7 @@ intel_sdvo_get_preferred_input_mode(struct intel_sdvo 
> > *intel_sdvo,
> > return false;
> >  
> > if (!intel_sdvo_create_preferred_input_timing(intel_sdvo,
> > + intel_sdvo_connector,
> >   mode->clock / 10,
> >   mode->hdisplay,
> >   mode->vdisplay))
> > @@ -1127,6 +1116,8 @@ static bool intel_sdvo_compute_config(struct 

Re: [Intel-gfx] [PATCH 1/2] drm/nouveau: Disable atomic support on a per-device basis

2018-09-17 Thread Lyude Paul
On Fri, 2018-09-14 at 10:11 +0200, Daniel Vetter wrote:
> On Thu, Sep 13, 2018 at 11:02 PM, Lyude Paul  wrote:
> > Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends
> > on
> > the driver supporting atomic, maybe it would be good to make it so that we
> > set
> > DRIVER_ATOMIC in the driver_stub structure, then disable it per-device
> > depending
> > on the nouveau_atomic setting + hw support. That way we can always have the
> > state debugfs file while maintaining nouveau's current behavior with
> > exposing
> > atomic ioctls. Assuming that wouldn't have any unintended side-effects of
> > course
> 
> dri/*/state only works with atomic drivers. There's no explicit state
> with legacy drivers at all, it's all just implicit in hw and some
> random driver structures.
> 
> We should make sure though that the debugfs stuff looks at
> drm_drv_uses_atomic_modsetting(), and not DRIVER_ATOMIC. Former is
> about the internals (i915 is internally atomic everywhere), latter
> about the uapi (some old platforms aren't properly validated for full
> atomic features, hence why it's disabled).
> -Daniel
Makes sense, it seems doing that results in exactly what I wanted with nouveau!
As for this patch:

Reviewed-by: Lyude Paul 

> 
> > On Thu, 2018-09-13 at 19:31 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > We now have per-device driver_features, so let's use that
> > > to disable atomic only for pre-nv50.
> > > 
> > > Cc: Ben Skeggs 
> > > Cc: Lyude Paul 
> > > Cc: nouv...@lists.freedesktop.org
> > > Cc: Daniel Vetter 
> > > Reviewed-by: Daniel Vetter 
> > > Suggested-by: Daniel Vetter 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > > b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > > index 70dce544984e..670535a68d3b 100644
> > > --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > > +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > > @@ -56,7 +56,7 @@ nv04_display_create(struct drm_device *dev)
> > >   nouveau_display(dev)->fini = nv04_display_fini;
> > > 
> > >   /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */
> > > - dev->driver->driver_features &= ~DRIVER_ATOMIC;
> > > + dev->driver_features &= ~DRIVER_ATOMIC;
> > > 
> > >   nouveau_hw_save_vga_fonts(dev, 1);
> > > 
> 
> 
> 

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Replace some PAGE_SHIFTs with I915_GTT_PAGE_SIZE

2018-09-17 Thread Patchwork
== Series Details ==

Series: drm/i915: Replace some PAGE_SHIFTs with I915_GTT_PAGE_SIZE
URL   : https://patchwork.freedesktop.org/series/49801/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
3ef2392b50ed drm/i915: Replace some PAGE_SHIFTs with I915_GTT_PAGE_SIZE
-:68: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#68: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:1889:
+   unsigned first_entry = vma->node.start / I915_GTT_PAGE_SIZE;

-:114: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#114: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:2544:
+   unsigned first_entry = start / I915_GTT_PAGE_SIZE;

-:115: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#115: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:2545:
+   unsigned num_entries = length / I915_GTT_PAGE_SIZE;

-:125: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#125: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:2660:
+   unsigned first_entry = start / I915_GTT_PAGE_SIZE;

-:126: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned'
#126: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:2661:
+   unsigned num_entries = length / I915_GTT_PAGE_SIZE;

total: 0 errors, 5 warnings, 0 checks, 104 lines checked

___
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/csr Added DC5 and DC6 counter register for ICL in debugfs entry.

2018-09-17 Thread Patchwork
== Series Details ==

Series: drm/i915/csr Added DC5 and DC6 counter register for ICL in debugfs 
entry.
URL   : https://patchwork.freedesktop.org/series/49800/
State : failure

== Summary ==

CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CHK include/generated/compile.h
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_dmc_info’:
drivers/gpu/drm/i915/i915_debugfs.c:2904:28: error: called object is not a 
function or function pointer
  (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))
  ~~^
scripts/Makefile.build:305: recipe for target 
'drivers/gpu/drm/i915/i915_debugfs.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_debugfs.o] Error 1
scripts/Makefile.build:546: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:546: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:546: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1062: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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


Re: [Intel-gfx] [PATCH 1/2] drm/i915/sdvo: Fix multi function encoder stuff

2018-09-17 Thread Rodrigo Vivi
On Mon, Sep 17, 2018 at 06:15:03PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> SDVO encoders can have multiple different types of outputs hanging off
> them. Currently the code tries to muck around with various is_foo
> flags in the encoder to figure out which type its driving. That doesn't
> work with atomic and other stuff, so let's nuke those flags and just
> look at which type of connector we're actually dealing with.
> 
> The is_hdmi we'll need as that's not discoverable via the output flags,
> but we'll just move it under the connector.
> 
> We'll also move the sdvo fixed mode handling out from the .get_modes()
> hook into the sdvo lvds init function so that we can bail out properly
> if there is no fixed mode to be found.

I wondered if this last part didn't deserved a separated patch. But not sure
how chicken-egg issue this could cause so maybe the same patch is better
indeed...

Reviewed-by: Rodrigo Vivi 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_sdvo.c | 101 
> +-
>  1 file changed, 44 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 812fe7b06f87..701372e512a8 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -99,31 +99,12 @@ struct intel_sdvo {
>*/
>   uint16_t hotplug_active;
>  
> - /**
> -  * This is set if we're going to treat the device as TV-out.
> -  *
> -  * While we have these nice friendly flags for output types that ought
> -  * to decide this for us, the S-Video output on our HDMI+S-Video card
> -  * shows up as RGB1 (VGA).
> -  */
> - bool is_tv;
> -
>   enum port port;
>  
> - /**
> -  * This is set if we treat the device as HDMI, instead of DVI.
> -  */
> - bool is_hdmi;
>   bool has_hdmi_monitor;
>   bool has_hdmi_audio;
>   bool rgb_quant_range_selectable;
>  
> - /**
> -  * This is set if we detect output of sdvo device as LVDS and
> -  * have a valid fixed mode to use with the panel.
> -  */
> - bool is_lvds;
> -
>   /**
>* This is sdvo fixed pannel mode pointer
>*/
> @@ -172,6 +153,11 @@ struct intel_sdvo_connector {
>  
>   /* this is to get the range of margin.*/
>   u32 max_hscan, max_vscan;
> +
> + /**
> +  * This is set if we treat the device as HDMI, instead of DVI.
> +  */
> + bool is_hdmi;
>  };
>  
>  struct intel_sdvo_connector_state {
> @@ -766,6 +752,7 @@ static bool intel_sdvo_get_input_timing(struct intel_sdvo 
> *intel_sdvo,
>  
>  static bool
>  intel_sdvo_create_preferred_input_timing(struct intel_sdvo *intel_sdvo,
> +  struct intel_sdvo_connector 
> *intel_sdvo_connector,
>uint16_t clock,
>uint16_t width,
>uint16_t height)
> @@ -778,7 +765,7 @@ intel_sdvo_create_preferred_input_timing(struct 
> intel_sdvo *intel_sdvo,
>   args.height = height;
>   args.interlace = 0;
>  
> - if (intel_sdvo->is_lvds &&
> + if (IS_LVDS(intel_sdvo_connector) &&
>  (intel_sdvo->sdvo_lvds_fixed_mode->hdisplay != width ||
>   intel_sdvo->sdvo_lvds_fixed_mode->vdisplay != height))
>   args.scaled = 1;
> @@ -1067,6 +1054,7 @@ intel_sdvo_set_output_timings_from_mode(struct 
> intel_sdvo *intel_sdvo,
>   */
>  static bool
>  intel_sdvo_get_preferred_input_mode(struct intel_sdvo *intel_sdvo,
> + struct intel_sdvo_connector 
> *intel_sdvo_connector,
>   const struct drm_display_mode *mode,
>   struct drm_display_mode *adjusted_mode)
>  {
> @@ -1077,6 +1065,7 @@ intel_sdvo_get_preferred_input_mode(struct intel_sdvo 
> *intel_sdvo,
>   return false;
>  
>   if (!intel_sdvo_create_preferred_input_timing(intel_sdvo,
> +   intel_sdvo_connector,
> mode->clock / 10,
> mode->hdisplay,
> mode->vdisplay))
> @@ -1127,6 +1116,8 @@ static bool intel_sdvo_compute_config(struct 
> intel_encoder *encoder,
>   struct intel_sdvo *intel_sdvo = to_sdvo(encoder);
>   struct intel_sdvo_connector_state *intel_sdvo_state =
>   to_intel_sdvo_connector_state(conn_state);
> + struct intel_sdvo_connector *intel_sdvo_connector =
> + to_intel_sdvo_connector(conn_state->connector);
>   struct drm_display_mode *adjusted_mode = 
> _config->base.adjusted_mode;
>   struct drm_display_mode *mode = _config->base.mode;
>  
> @@ -1142,20 +1133,22 @@ static bool intel_sdvo_compute_config(struct 
> intel_encoder *encoder,
>* 

[Intel-gfx] [PATCH] drm/i915: Replace some PAGE_SHIFTs with I915_GTT_PAGE_SIZE

2018-09-17 Thread Ville Syrjala
From: Ville Syrjälä 

Clean up some cases where we're dealing with GTT pages instead of
system pages to use I915_GTT_PAGE_SIZE instead of PAGE_SHIT. So
just replace the the shifts with mul/div as appropriate. These
are the easy ones, the rest probably need some actual thought.

No real changes in the generated asm. Only gen8_ppgtt_insert_4lvl()
was affected as gcc decided to do the following change:
- be9:   89 d9   mov%ebx,%ecx
- beb:   c1 e1 0cshl$0xc,%ecx
- bee:   48 63 c9movslq %ecx,%rcx
+ be9:   48 63 cbmovslq %ebx,%rcx
+ bec:   48 c1 e1 0c shl$0xc,%rcx
and that then shifted a bunch of the offset by one byte. I presume
the sign extensions in the asm are due to integer promotions from
u16 etc. Hopefully someone has confirmed that those don't end up
doing the wrong thing for us.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8be1acd097db..4877d4d582c2 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1144,7 +1144,7 @@ static void gen8_ppgtt_insert_huge_entries(struct 
i915_vma *vma,
vma->page_sizes.sg & I915_GTT_PAGE_SIZE_64K &&
IS_ALIGNED(iter->dma, I915_GTT_PAGE_SIZE_64K) &&
(IS_ALIGNED(rem, I915_GTT_PAGE_SIZE_64K) ||
-rem >= (max - index) << PAGE_SHIFT))
+rem >= (max - index) * I915_GTT_PAGE_SIZE))
maybe_64K = true;
 
vaddr = kmap_atomic_px(pt);
@@ -1169,7 +1169,7 @@ static void gen8_ppgtt_insert_huge_entries(struct 
i915_vma *vma,
if (maybe_64K && index < max &&
!(IS_ALIGNED(iter->dma, 
I915_GTT_PAGE_SIZE_64K) &&
  (IS_ALIGNED(rem, I915_GTT_PAGE_SIZE_64K) 
||
-  rem >= (max - index) << PAGE_SHIFT)))
+  rem >= (max - index) * 
I915_GTT_PAGE_SIZE)))
maybe_64K = false;
 
if (unlikely(!IS_ALIGNED(iter->dma, page_size)))
@@ -1842,10 +1842,10 @@ static void gen6_ppgtt_clear_range(struct 
i915_address_space *vm,
   u64 start, u64 length)
 {
struct gen6_hw_ppgtt *ppgtt = to_gen6_ppgtt(i915_vm_to_ppgtt(vm));
-   unsigned int first_entry = start >> PAGE_SHIFT;
+   unsigned int first_entry = start / I915_GTT_PAGE_SIZE;
unsigned int pde = first_entry / GEN6_PTES;
unsigned int pte = first_entry % GEN6_PTES;
-   unsigned int num_entries = length >> PAGE_SHIFT;
+   unsigned int num_entries = length / I915_GTT_PAGE_SIZE;
const gen6_pte_t scratch_pte = ppgtt->scratch_pte;
 
while (num_entries) {
@@ -1886,7 +1886,7 @@ static void gen6_ppgtt_insert_entries(struct 
i915_address_space *vm,
  u32 flags)
 {
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
-   unsigned first_entry = vma->node.start >> PAGE_SHIFT;
+   unsigned first_entry = vma->node.start / I915_GTT_PAGE_SIZE;
unsigned act_pt = first_entry / GEN6_PTES;
unsigned act_pte = first_entry % GEN6_PTES;
const u32 pte_encode = vm->pte_encode(0, cache_level, flags);
@@ -2456,7 +2456,7 @@ static void gen8_ggtt_insert_page(struct 
i915_address_space *vm,
 {
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
gen8_pte_t __iomem *pte =
-   (gen8_pte_t __iomem *)ggtt->gsm + (offset >> PAGE_SHIFT);
+   (gen8_pte_t __iomem *)ggtt->gsm + offset / I915_GTT_PAGE_SIZE;
 
gen8_set_pte(pte, gen8_pte_encode(addr, level, 0));
 
@@ -2480,7 +2480,7 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
 */
 
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
-   gtt_entries += vma->node.start >> PAGE_SHIFT;
+   gtt_entries += vma->node.start / I915_GTT_PAGE_SIZE;
for_each_sgt_dma(addr, sgt_iter, vma->pages)
gen8_set_pte(gtt_entries++, pte_encode | addr);
 
@@ -2499,7 +2499,7 @@ static void gen6_ggtt_insert_page(struct 
i915_address_space *vm,
 {
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
gen6_pte_t __iomem *pte =
-   (gen6_pte_t __iomem *)ggtt->gsm + (offset >> PAGE_SHIFT);
+   (gen6_pte_t __iomem *)ggtt->gsm + offset / I915_GTT_PAGE_SIZE;
 
iowrite32(vm->pte_encode(addr, level, flags), pte);
 
@@ -2519,7 +2519,7 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
 {
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
gen6_pte_t 

Re: [Intel-gfx] [PATCH] [intel-gfx] drm/i915/csr Added DC5 and DC6 counter register for ICL in debugfs entry.

2018-09-17 Thread Rodrigo Vivi
On Mon, Sep 17, 2018 at 12:49:35PM -0400, Jyoti Yadav wrote:
> DC5 and DC6 counter register tells about residency of DC5 and DC6.
> These registers are same for SKL and ICL.
> 
> Signed-off-by: Jyoti Yadav 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
>  drivers/gpu/drm/i915/i915_reg.h | 1 +
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a5265c2..328e39c 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2898,7 +2898,8 @@ static int i915_dmc_info(struct seq_file *m, void 
> *unused)
>  CSR_VERSION_MINOR(csr->version));
>  
>   if (IS_KABYLAKE(dev_priv) ||
> - (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))) {
> + (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))
> + (IS_ICELAKE(dev_priv) && csr->version >= CSR_VERSION(1, 7))) {

Why on ICELAKE we need to be greater than version 1.7?
Specially because our only version starts on 1.7 I don't believe we should
be checking version here.

Also SKL check is useless nowadays and should be removed. It came from
the times we didn't have tied version of kernel and firmware...

Also I'm missing CFL, BXT, GLK and CNL on this range here...

Probably good to replace everything

if gen >= 9 && gen <= 11

?

>   seq_printf(m, "DC3 -> DC5 count: %d\n",
>  I915_READ(SKL_CSR_DC3_DC5_COUNT));
>   seq_printf(m, "DC5 -> DC6 count: %d\n",
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8534f88..573d5f3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6985,6 +6985,7 @@ enum {
>  /* MMIO address range for CSR program (0x8 - 0x82FFF) */
>  #define CSR_MMIO_START_RANGE 0x8
>  #define CSR_MMIO_END_RANGE   0x8
> +/* DC3_DC5 count and DC5_DC6 count registers are same for SKL and ICL */
>  #define SKL_CSR_DC3_DC5_COUNT_MMIO(0x80030)
>  #define SKL_CSR_DC5_DC6_COUNT_MMIO(0x8002C)
>  #define BXT_CSR_DC3_DC5_COUNT_MMIO(0x80038)
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] [intel-gfx] drm/i915/csr Added DC5 and DC6 counter register for ICL in debugfs entry.

2018-09-17 Thread Jyoti Yadav
DC5 and DC6 counter register tells about residency of DC5 and DC6.
These registers are same for SKL and ICL.

Signed-off-by: Jyoti Yadav 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a5265c2..328e39c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2898,7 +2898,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
   CSR_VERSION_MINOR(csr->version));
 
if (IS_KABYLAKE(dev_priv) ||
-   (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))) {
+   (IS_SKYLAKE(dev_priv) && csr->version >= CSR_VERSION(1, 6))
+   (IS_ICELAKE(dev_priv) && csr->version >= CSR_VERSION(1, 7))) {
seq_printf(m, "DC3 -> DC5 count: %d\n",
   I915_READ(SKL_CSR_DC3_DC5_COUNT));
seq_printf(m, "DC5 -> DC6 count: %d\n",
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8534f88..573d5f3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6985,6 +6985,7 @@ enum {
 /* MMIO address range for CSR program (0x8 - 0x82FFF) */
 #define CSR_MMIO_START_RANGE   0x8
 #define CSR_MMIO_END_RANGE 0x8
+/* DC3_DC5 count and DC5_DC6 count registers are same for SKL and ICL */
 #define SKL_CSR_DC3_DC5_COUNT  _MMIO(0x80030)
 #define SKL_CSR_DC5_DC6_COUNT  _MMIO(0x8002C)
 #define BXT_CSR_DC3_DC5_COUNT  _MMIO(0x80038)
-- 
1.9.1

___
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 [1/2] drm/i915/sdvo: Fix multi function encoder stuff

2018-09-17 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/sdvo: Fix multi function encoder 
stuff
URL   : https://patchwork.freedesktop.org/series/49795/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4833_full -> Patchwork_10204_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

  Here are the changes found in Patchwork_10204_full that come from known 
issues:

  === IGT changes ===

 Issues hit 

igt@gem_ppgtt@blt-vs-render-ctxn:
  shard-kbl:  PASS -> INCOMPLETE (fdo#106023, fdo#103665)

igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
  shard-apl:  PASS -> DMESG-WARN (fdo#107956)

igt@kms_flip@2x-flip-vs-expired-vblank:
  shard-glk:  PASS -> FAIL (fdo#105363)


 Possible fixes 

igt@kms_frontbuffer_tracking@fbc-stridechange:
  shard-glk:  FAIL (fdo#103167) -> PASS

igt@kms_setmode@basic:
  shard-apl:  FAIL (fdo#99912) -> PASS


  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4833 -> Patchwork_10204

  CI_DRM_4833: 75bb460b367a614d10b0fba220143bee42657d7e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4644: 0b59bb3231ab481959528c5c7b3a98762772e1b0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10204: 8a795501a8cf58a8abb713bf74e454271e7fd6c1 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


Re: [Intel-gfx] [PATCH i-g-t 2/2] gem_ctx_exec: Remove lrc-lite-restore

2018-09-17 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-09-17 16:46:19)
> From: Tvrtko Ursulin 
> 
> Lite restore is sufficiently covered in gem_exec_nop.
> 
> At the same time tidy code in the test a bit to bring it closer to today's
> coding style.
> 
> Signed-off-by: Tvrtko Ursulin 
> Suggested-by: Chris Wilson 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/2] tests/gem_ctx_bad_exec: Consolidate to gem_ctx_exec

2018-09-17 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-09-17 16:46:18)
> From: Tvrtko Ursulin 
> 
> Move a really small test that invalid context is rejected under the
> gem_ctx_exec umbrella.
> 
> v2:
>  * And actually fix the test so it does what it claims. And add more
>variety in the invalid context id's it tests with. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> ---
>  tests/Makefile.sources   |  1 -
>  tests/gem_ctx_bad_exec.c | 60 
>  tests/gem_ctx_exec.c | 34 +++
>  tests/meson.build|  1 -
>  4 files changed, 34 insertions(+), 62 deletions(-)
>  delete mode 100644 tests/gem_ctx_bad_exec.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index c84933f1d971..269336ad3150 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -51,7 +51,6 @@ TESTS_progs = \
> gem_cs_prefetch \
> gem_cs_tlb \
> gem_ctx_bad_destroy \
> -   gem_ctx_bad_exec \
> gem_ctx_create \
> gem_ctx_exec \
> gem_ctx_isolation \
> diff --git a/tests/gem_ctx_bad_exec.c b/tests/gem_ctx_bad_exec.c
> deleted file mode 100644
> index e3ccc5be46a0..
> --- a/tests/gem_ctx_bad_exec.c
> +++ /dev/null
> @@ -1,60 +0,0 @@
> -/*
> - * Copyright © 2012 Intel Corporation
> - *
> - * Permission is hereby granted, free of charge, to any person obtaining a
> - * copy of this software and associated documentation files (the "Software"),
> - * to deal in the Software without restriction, including without limitation
> - * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> - * and/or sell copies of the Software, and to permit persons to whom the
> - * Software is furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice (including the next
> - * paragraph) shall be included in all copies or substantial portions of the
> - * Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> - * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> - * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> - * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> - * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> - * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> - * IN THE SOFTWARE.
> - *
> - */
> -
> -#include "igt.h"
> -
> -IGT_TEST_DESCRIPTION("Test that context cannot be submitted to any ring");
> -
> -static int exec(int fd, unsigned ring)
> -{
> -   struct drm_i915_gem_execbuffer2 execbuf;
> -   struct drm_i915_gem_exec_object2 obj;
> -
> -   memset(, 0, sizeof(obj));
> -   memset(, 0, sizeof(execbuf));
> -
> -   execbuf.buffers_ptr = to_user_pointer();
> -   execbuf.buffer_count = 1;
> -   i915_execbuffer2_set_context_id(execbuf, 1);
> -
> -   return __gem_execbuf(fd, );
> -}
> -
> -igt_main
> -{
> -   const struct intel_execution_engine *e;
> -   int fd = -1;
> -
> -   igt_skip_on_simulation();
> -
> -   igt_fixture
> -   fd = drm_open_driver_render(DRIVER_INTEL);
> -
> -   for (e = intel_execution_engines; e->name; e++) {
> -   igt_subtest_f("%s", e->name) {
> -   gem_require_ring(fd, e->exec_id | e->flags);
> -   igt_assert_eq(exec(fd, e->exec_id | e->flags), 
> -ENOENT);
> -   }
> -   }
> -}
> diff --git a/tests/gem_ctx_exec.c b/tests/gem_ctx_exec.c
> index 1f8ed64d4bd3..4ed6febe12b8 100644
> --- a/tests/gem_ctx_exec.c
> +++ b/tests/gem_ctx_exec.c
> @@ -30,6 +30,7 @@
>   */
>  
>  #include "igt.h"
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -142,6 +143,30 @@ static void big_exec(int fd, uint32_t handle, int ring)
> gem_sync(fd, handle);
>  }
>  
> +static void invalid_context(int fd, unsigned ring, uint32_t handle)
> +{
> +   struct drm_i915_gem_exec_object2 obj = {
> +   .handle = handle,
> +   };
> +   struct drm_i915_gem_execbuffer2 execbuf = {
> +   .buffers_ptr = to_user_pointer(),
> +   .buffer_count = 1,
> +   .flags = ring,
> +   };
> +   const uint64_t invalid[] = { 1, INT_MAX, UINT_MAX, LONG_MAX, 
> ULONG_MAX,
> +LLONG_MAX, ULLONG_MAX };

The field is only a u32. Strange you didn't notice that amidst the
absence of documentation ;)

Trim this array to suite, and
Reviewed-by: Chris Wilson 
-Chris
___
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] gem_ctx_exec: Remove lrc-lite-restore

2018-09-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Lite restore is sufficiently covered in gem_exec_nop.

At the same time tidy code in the test a bit to bring it closer to today's
coding style.

Signed-off-by: Tvrtko Ursulin 
Suggested-by: Chris Wilson 
---
 tests/gem_ctx_exec.c | 116 +++
 1 file changed, 28 insertions(+), 88 deletions(-)

diff --git a/tests/gem_ctx_exec.c b/tests/gem_ctx_exec.c
index 4ed6febe12b8..b0f7b61e90be 100644
--- a/tests/gem_ctx_exec.c
+++ b/tests/gem_ctx_exec.c
@@ -24,11 +24,6 @@
  *Ben Widawsky 
  *
  */
-
-/*
- * This test covers basic context switch functionality
- */
-
 #include "igt.h"
 #include 
 #include 
@@ -46,44 +41,32 @@
 #include 
 
 
-IGT_TEST_DESCRIPTION("Test basic context switch functionality.");
+IGT_TEST_DESCRIPTION("Test context batch buffer execution.");
 
 /* Copied from gem_exec_nop.c */
 static int exec(int fd, uint32_t handle, int ring, int ctx_id)
 {
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 gem_exec;
-
-   gem_exec.handle = handle;
-   gem_exec.relocation_count = 0;
-   gem_exec.relocs_ptr = 0;
-   gem_exec.alignment = 0;
-   gem_exec.offset = 0;
-   gem_exec.flags = 0;
-   gem_exec.rsvd1 = 0;
-   gem_exec.rsvd2 = 0;
-
-   execbuf.buffers_ptr = to_user_pointer(_exec);
-   execbuf.buffer_count = 1;
-   execbuf.batch_start_offset = 0;
-   execbuf.batch_len = 8;
-   execbuf.cliprects_ptr = 0;
-   execbuf.num_cliprects = 0;
-   execbuf.DR1 = 0;
-   execbuf.DR4 = 0;
-   execbuf.flags = ring;
+   struct drm_i915_gem_exec_object2 obj = { .handle = handle };
+   struct drm_i915_gem_execbuffer2 execbuf = {
+   .buffers_ptr = to_user_pointer(),
+   .buffer_count = 1,
+   .flags = ring,
+   };
+
i915_execbuffer2_set_context_id(execbuf, ctx_id);
-   execbuf.rsvd2 = 0;
 
return __gem_execbuf(fd, );
 }
 
 static void big_exec(int fd, uint32_t handle, int ring)
 {
-   struct drm_i915_gem_execbuffer2 execbuf;
+   int num_buffers = gem_global_aperture_size(fd) / 4096;
+   struct drm_i915_gem_execbuffer2 execbuf = {
+   .buffer_count = num_buffers,
+   .flags = ring,
+   };
struct drm_i915_gem_exec_object2 *gem_exec;
uint32_t ctx_id1, ctx_id2;
-   int num_buffers = gem_global_aperture_size(fd) / 4096;
int i;
 
/* Make sure we only fill half of RAM with gem objects. */
@@ -93,33 +76,19 @@ static void big_exec(int fd, uint32_t handle, int ring)
igt_assert(gem_exec);
memset(gem_exec, 0, (num_buffers + 1) * sizeof(*gem_exec));
 
-
ctx_id1 = gem_context_create(fd);
ctx_id2 = gem_context_create(fd);
 
gem_exec[0].handle = handle;
 
-
execbuf.buffers_ptr = to_user_pointer(gem_exec);
-   execbuf.buffer_count = num_buffers + 1;
-   execbuf.batch_start_offset = 0;
-   execbuf.batch_len = 8;
-   execbuf.cliprects_ptr = 0;
-   execbuf.num_cliprects = 0;
-   execbuf.DR1 = 0;
-   execbuf.DR4 = 0;
-   execbuf.flags = ring;
-   execbuf.rsvd2 = 0;
 
execbuf.buffer_count = 1;
i915_execbuffer2_set_context_id(execbuf, ctx_id1);
gem_execbuf(fd, );
 
-   for (i = 0; i < num_buffers; i++) {
-   uint32_t tmp_handle = gem_create(fd, 4096);
-
-   gem_exec[i].handle = tmp_handle;
-   }
+   for (i = 0; i < num_buffers; i++)
+   gem_exec[i].handle = gem_create(fd, 4096);
gem_exec[i].handle = handle;
execbuf.buffer_count = i + 1;
 
@@ -132,8 +101,7 @@ static void big_exec(int fd, uint32_t handle, int ring)
igt_info("trying buffer count %i\n", i - 1);
}
 
-   igt_info("reduced buffer count to %i from %i\n",
-  i - 1, num_buffers);
+   igt_info("reduced buffer count to %i from %i\n", i - 1, num_buffers);
 
/* double check that it works */
gem_execbuf(fd, );
@@ -167,14 +135,13 @@ static void invalid_context(int fd, unsigned ring, 
uint32_t handle)
}
 }
 
-uint32_t handle;
-uint32_t batch[2] = {0, MI_BATCH_BUFFER_END};
-uint32_t ctx_id, ctx_id2;
-int fd;
-
 igt_main
 {
+   const uint32_t batch[2] = { 0, MI_BATCH_BUFFER_END };
const struct intel_execution_engine *e;
+   uint32_t handle;
+   uint32_t ctx_id;
+   int fd;
 
igt_fixture {
fd = drm_open_driver_render(DRIVER_INTEL);
@@ -188,16 +155,16 @@ igt_main
 
igt_subtest("basic") {
ctx_id = gem_context_create(fd);
-   igt_assert(exec(fd, handle, I915_EXEC_RENDER, ctx_id) == 0);
+   igt_assert(exec(fd, handle, 0, ctx_id) == 0);
gem_sync(fd, handle);
gem_context_destroy(fd, ctx_id);
 
ctx_id = gem_context_create(fd);
-   igt_assert(exec(fd, handle, I915_EXEC_RENDER, ctx_id) == 0);
+   

[Intel-gfx] [PATCH i-g-t 1/2] tests/gem_ctx_bad_exec: Consolidate to gem_ctx_exec

2018-09-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Move a really small test that invalid context is rejected under the
gem_ctx_exec umbrella.

v2:
 * And actually fix the test so it does what it claims. And add more
   variety in the invalid context id's it tests with. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 tests/Makefile.sources   |  1 -
 tests/gem_ctx_bad_exec.c | 60 
 tests/gem_ctx_exec.c | 34 +++
 tests/meson.build|  1 -
 4 files changed, 34 insertions(+), 62 deletions(-)
 delete mode 100644 tests/gem_ctx_bad_exec.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c84933f1d971..269336ad3150 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -51,7 +51,6 @@ TESTS_progs = \
gem_cs_prefetch \
gem_cs_tlb \
gem_ctx_bad_destroy \
-   gem_ctx_bad_exec \
gem_ctx_create \
gem_ctx_exec \
gem_ctx_isolation \
diff --git a/tests/gem_ctx_bad_exec.c b/tests/gem_ctx_bad_exec.c
deleted file mode 100644
index e3ccc5be46a0..
--- a/tests/gem_ctx_bad_exec.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * Copyright © 2012 Intel Corporation
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
- * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
- * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
- * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
- * IN THE SOFTWARE.
- *
- */
-
-#include "igt.h"
-
-IGT_TEST_DESCRIPTION("Test that context cannot be submitted to any ring");
-
-static int exec(int fd, unsigned ring)
-{
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 obj;
-
-   memset(, 0, sizeof(obj));
-   memset(, 0, sizeof(execbuf));
-
-   execbuf.buffers_ptr = to_user_pointer();
-   execbuf.buffer_count = 1;
-   i915_execbuffer2_set_context_id(execbuf, 1);
-
-   return __gem_execbuf(fd, );
-}
-
-igt_main
-{
-   const struct intel_execution_engine *e;
-   int fd = -1;
-
-   igt_skip_on_simulation();
-
-   igt_fixture
-   fd = drm_open_driver_render(DRIVER_INTEL);
-
-   for (e = intel_execution_engines; e->name; e++) {
-   igt_subtest_f("%s", e->name) {
-   gem_require_ring(fd, e->exec_id | e->flags);
-   igt_assert_eq(exec(fd, e->exec_id | e->flags), -ENOENT);
-   }
-   }
-}
diff --git a/tests/gem_ctx_exec.c b/tests/gem_ctx_exec.c
index 1f8ed64d4bd3..4ed6febe12b8 100644
--- a/tests/gem_ctx_exec.c
+++ b/tests/gem_ctx_exec.c
@@ -30,6 +30,7 @@
  */
 
 #include "igt.h"
+#include 
 #include 
 #include 
 #include 
@@ -142,6 +143,30 @@ static void big_exec(int fd, uint32_t handle, int ring)
gem_sync(fd, handle);
 }
 
+static void invalid_context(int fd, unsigned ring, uint32_t handle)
+{
+   struct drm_i915_gem_exec_object2 obj = {
+   .handle = handle,
+   };
+   struct drm_i915_gem_execbuffer2 execbuf = {
+   .buffers_ptr = to_user_pointer(),
+   .buffer_count = 1,
+   .flags = ring,
+   };
+   const uint64_t invalid[] = { 1, INT_MAX, UINT_MAX, LONG_MAX, ULONG_MAX,
+LLONG_MAX, ULLONG_MAX };
+   int i;
+
+   /* Verify all works. */
+   gem_execbuf(fd, );
+
+   /* Go through some non-existent context id's. */
+   for (i = 0; i < ARRAY_SIZE(invalid); i++) {
+   i915_execbuffer2_set_context_id(execbuf, invalid[i]);
+   igt_assert_eq(__gem_execbuf(fd, ), -ENOENT);
+   }
+}
+
 uint32_t handle;
 uint32_t batch[2] = {0, MI_BATCH_BUFFER_END};
 uint32_t ctx_id, ctx_id2;
@@ -149,6 +174,8 @@ int fd;
 
 igt_main
 {
+   const struct intel_execution_engine *e;
+
igt_fixture {
fd = drm_open_driver_render(DRIVER_INTEL);
igt_require_gem(fd);
@@ -174,6 +201,13 @@ igt_main
gem_sync(fd, handle);
}
 
+   for (e = intel_execution_engines; e->name; e++) {
+   igt_subtest_f("invalid-context-%s", e->name) {
+ 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/sdvo: Fix multi function encoder stuff

2018-09-17 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/sdvo: Fix multi function encoder 
stuff
URL   : https://patchwork.freedesktop.org/series/49795/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4833 -> Patchwork_10204 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/49795/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_10204 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-skl-caroline:NOTRUN -> INCOMPLETE (fdo#107556, fdo#104108)

igt@kms_frontbuffer_tracking@basic:
  fi-byt-clapper: PASS -> FAIL (fdo#103167)

igt@kms_pipe_crc_basic@hang-read-crc-pipe-b:
  fi-byt-clapper: PASS -> FAIL (fdo#107362, fdo#103191)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-skl-6700k2:  PASS -> FAIL (fdo#103191)

igt@kms_psr@primary_mmap_gtt:
  {fi-cnl-u}: NOTRUN -> FAIL (fdo#107383) +3

igt@kms_psr@primary_page_flip:
  fi-kbl-7560u:   PASS -> FAIL (fdo#107336)


 Possible fixes 

igt@drv_module_reload@basic-reload:
  fi-blb-e6850:   INCOMPLETE (fdo#107718) -> PASS

igt@drv_selftest@live_hangcheck:
  fi-glk-j4005:   INCOMPLETE (fdo#103359, k.org#198133) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-icl-u:   INCOMPLETE (fdo#107713) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   DMESG-FAIL (fdo#103713) -> PASS

igt@kms_psr@primary_page_flip:
  fi-kbl-r:   FAIL (fdo#107336) -> PASS

igt@kms_setmode@basic-clone-single-crtc:
  fi-snb-2520m:   DMESG-WARN (fdo#103713) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
  fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
  fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556
  fdo#107713 https://bugs.freedesktop.org/show_bug.cgi?id=107713
  fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (46 -> 42) ==

  Additional (2): fi-cnl-u fi-skl-caroline 
  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bdw-gvtdvm fi-byt-squawks 
fi-bsw-cyan fi-bsw-kefka 


== Build changes ==

* Linux: CI_DRM_4833 -> Patchwork_10204

  CI_DRM_4833: 75bb460b367a614d10b0fba220143bee42657d7e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4644: 0b59bb3231ab481959528c5c7b3a98762772e1b0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10204: 8a795501a8cf58a8abb713bf74e454271e7fd6c1 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

8a795501a8cf drm/i915/sdvo: Utilize intel_panel for fixed_mode
61a7c71555be drm/i915/sdvo: Fix multi function encoder stuff

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/sdvo: Fix multi function encoder stuff

2018-09-17 Thread Patchwork
== Series Details ==

Series: series starting with [1/2] drm/i915/sdvo: Fix multi function encoder 
stuff
URL   : https://patchwork.freedesktop.org/series/49795/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
61a7c71555be drm/i915/sdvo: Fix multi function encoder stuff
-:86: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#86: FILE: drivers/gpu/drm/i915/intel_sdvo.c:769:
+   if (IS_LVDS(intel_sdvo_connector) &&
   (intel_sdvo->sdvo_lvds_fixed_mode->hdisplay != width ||

total: 0 errors, 0 warnings, 1 checks, 271 lines checked
8a795501a8cf drm/i915/sdvo: Utilize intel_panel for fixed_mode
-:54: WARNING:LONG_LINE: line over 100 characters
#54: FILE: drivers/gpu/drm/i915/intel_sdvo.c:1146:
+
intel_sdvo_connector->base.panel.fixed_mode))

total: 0 errors, 1 warnings, 0 checks, 95 lines checked

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


[Intel-gfx] [PATCH 1/2] drm/i915/sdvo: Fix multi function encoder stuff

2018-09-17 Thread Ville Syrjala
From: Ville Syrjälä 

SDVO encoders can have multiple different types of outputs hanging off
them. Currently the code tries to muck around with various is_foo
flags in the encoder to figure out which type its driving. That doesn't
work with atomic and other stuff, so let's nuke those flags and just
look at which type of connector we're actually dealing with.

The is_hdmi we'll need as that's not discoverable via the output flags,
but we'll just move it under the connector.

We'll also move the sdvo fixed mode handling out from the .get_modes()
hook into the sdvo lvds init function so that we can bail out properly
if there is no fixed mode to be found.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sdvo.c | 101 +-
 1 file changed, 44 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 812fe7b06f87..701372e512a8 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -99,31 +99,12 @@ struct intel_sdvo {
 */
uint16_t hotplug_active;
 
-   /**
-* This is set if we're going to treat the device as TV-out.
-*
-* While we have these nice friendly flags for output types that ought
-* to decide this for us, the S-Video output on our HDMI+S-Video card
-* shows up as RGB1 (VGA).
-*/
-   bool is_tv;
-
enum port port;
 
-   /**
-* This is set if we treat the device as HDMI, instead of DVI.
-*/
-   bool is_hdmi;
bool has_hdmi_monitor;
bool has_hdmi_audio;
bool rgb_quant_range_selectable;
 
-   /**
-* This is set if we detect output of sdvo device as LVDS and
-* have a valid fixed mode to use with the panel.
-*/
-   bool is_lvds;
-
/**
 * This is sdvo fixed pannel mode pointer
 */
@@ -172,6 +153,11 @@ struct intel_sdvo_connector {
 
/* this is to get the range of margin.*/
u32 max_hscan, max_vscan;
+
+   /**
+* This is set if we treat the device as HDMI, instead of DVI.
+*/
+   bool is_hdmi;
 };
 
 struct intel_sdvo_connector_state {
@@ -766,6 +752,7 @@ static bool intel_sdvo_get_input_timing(struct intel_sdvo 
*intel_sdvo,
 
 static bool
 intel_sdvo_create_preferred_input_timing(struct intel_sdvo *intel_sdvo,
+struct intel_sdvo_connector 
*intel_sdvo_connector,
 uint16_t clock,
 uint16_t width,
 uint16_t height)
@@ -778,7 +765,7 @@ intel_sdvo_create_preferred_input_timing(struct intel_sdvo 
*intel_sdvo,
args.height = height;
args.interlace = 0;
 
-   if (intel_sdvo->is_lvds &&
+   if (IS_LVDS(intel_sdvo_connector) &&
   (intel_sdvo->sdvo_lvds_fixed_mode->hdisplay != width ||
intel_sdvo->sdvo_lvds_fixed_mode->vdisplay != height))
args.scaled = 1;
@@ -1067,6 +1054,7 @@ intel_sdvo_set_output_timings_from_mode(struct intel_sdvo 
*intel_sdvo,
  */
 static bool
 intel_sdvo_get_preferred_input_mode(struct intel_sdvo *intel_sdvo,
+   struct intel_sdvo_connector 
*intel_sdvo_connector,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
@@ -1077,6 +1065,7 @@ intel_sdvo_get_preferred_input_mode(struct intel_sdvo 
*intel_sdvo,
return false;
 
if (!intel_sdvo_create_preferred_input_timing(intel_sdvo,
+ intel_sdvo_connector,
  mode->clock / 10,
  mode->hdisplay,
  mode->vdisplay))
@@ -1127,6 +1116,8 @@ static bool intel_sdvo_compute_config(struct 
intel_encoder *encoder,
struct intel_sdvo *intel_sdvo = to_sdvo(encoder);
struct intel_sdvo_connector_state *intel_sdvo_state =
to_intel_sdvo_connector_state(conn_state);
+   struct intel_sdvo_connector *intel_sdvo_connector =
+   to_intel_sdvo_connector(conn_state->connector);
struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
struct drm_display_mode *mode = _config->base.mode;
 
@@ -1142,20 +1133,22 @@ static bool intel_sdvo_compute_config(struct 
intel_encoder *encoder,
 * timings, even though this isn't really the right place in
 * the sequence to do it. Oh well.
 */
-   if (intel_sdvo->is_tv) {
+   if (IS_TV(intel_sdvo_connector)) {
if (!intel_sdvo_set_output_timings_from_mode(intel_sdvo, mode))
return false;
 
(void) intel_sdvo_get_preferred_input_mode(intel_sdvo,
+ 

[Intel-gfx] [PATCH 2/2] drm/i915/sdvo: Utilize intel_panel for fixed_mode

2018-09-17 Thread Ville Syrjala
From: Ville Syrjälä 

Remove the local lvds fixed mode pointer from the sdvo encoder
structure and instead utilize intel_panel like everyone else.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sdvo.c | 40 ---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 701372e512a8..11e8d598702e 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -105,11 +105,6 @@ struct intel_sdvo {
bool has_hdmi_audio;
bool rgb_quant_range_selectable;
 
-   /**
-* This is sdvo fixed pannel mode pointer
-*/
-   struct drm_display_mode *sdvo_lvds_fixed_mode;
-
/* DDC bus used by this SDVO encoder */
uint8_t ddc_bus;
 
@@ -765,10 +760,14 @@ intel_sdvo_create_preferred_input_timing(struct 
intel_sdvo *intel_sdvo,
args.height = height;
args.interlace = 0;
 
-   if (IS_LVDS(intel_sdvo_connector) &&
-  (intel_sdvo->sdvo_lvds_fixed_mode->hdisplay != width ||
-   intel_sdvo->sdvo_lvds_fixed_mode->vdisplay != height))
-   args.scaled = 1;
+   if (IS_LVDS(intel_sdvo_connector)) {
+   const struct drm_display_mode *fixed_mode =
+   intel_sdvo_connector->base.panel.fixed_mode;
+
+   if (fixed_mode->hdisplay != width ||
+   fixed_mode->vdisplay != height)
+   args.scaled = 1;
+   }
 
return intel_sdvo_set_value(intel_sdvo,
SDVO_CMD_CREATE_PREFERRED_INPUT_TIMING,
@@ -1144,7 +1143,7 @@ static bool intel_sdvo_compute_config(struct 
intel_encoder *encoder,
pipe_config->sdvo_tv_clock = true;
} else if (IS_LVDS(intel_sdvo_connector)) {
if (!intel_sdvo_set_output_timings_from_mode(intel_sdvo,
-
intel_sdvo->sdvo_lvds_fixed_mode))
+
intel_sdvo_connector->base.panel.fixed_mode))
return false;
 
(void) intel_sdvo_get_preferred_input_mode(intel_sdvo,
@@ -1301,7 +1300,7 @@ static void intel_sdvo_pre_enable(struct intel_encoder 
*intel_encoder,
/* lvds has a special fixed output timing. */
if (IS_LVDS(intel_sdvo_connector))
intel_sdvo_get_dtd_from_mode(_dtd,
-intel_sdvo->sdvo_lvds_fixed_mode);
+
intel_sdvo_connector->base.panel.fixed_mode);
else
intel_sdvo_get_dtd_from_mode(_dtd, mode);
if (!intel_sdvo_set_output_timing(intel_sdvo, _dtd))
@@ -1642,10 +1641,13 @@ intel_sdvo_mode_valid(struct drm_connector *connector,
return MODE_CLOCK_HIGH;
 
if (IS_LVDS(intel_sdvo_connector)) {
-   if (mode->hdisplay > intel_sdvo->sdvo_lvds_fixed_mode->hdisplay)
+   const struct drm_display_mode *fixed_mode =
+   intel_sdvo_connector->base.panel.fixed_mode;
+
+   if (mode->hdisplay > fixed_mode->hdisplay)
return MODE_PANEL;
 
-   if (mode->vdisplay > intel_sdvo->sdvo_lvds_fixed_mode->vdisplay)
+   if (mode->vdisplay > fixed_mode->vdisplay)
return MODE_PANEL;
}
 
@@ -2063,6 +2065,7 @@ static void intel_sdvo_destroy(struct drm_connector 
*connector)
struct intel_sdvo_connector *intel_sdvo_connector = 
to_intel_sdvo_connector(connector);
 
drm_connector_cleanup(connector);
+   intel_panel_fini(_sdvo_connector->base.panel);
kfree(intel_sdvo_connector);
 }
 
@@ -2267,10 +2270,6 @@ static void intel_sdvo_enc_destroy(struct drm_encoder 
*encoder)
 {
struct intel_sdvo *intel_sdvo = to_sdvo(to_intel_encoder(encoder));
 
-   if (intel_sdvo->sdvo_lvds_fixed_mode != NULL)
-   drm_mode_destroy(encoder->dev,
-intel_sdvo->sdvo_lvds_fixed_mode);
-
i2c_del_adapter(_sdvo->ddc);
intel_encoder_destroy(encoder);
 }
@@ -2663,13 +2662,16 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo, int 
device)
 
list_for_each_entry(mode, >probed_modes, head) {
if (mode->type & DRM_MODE_TYPE_PREFERRED) {
-   intel_sdvo->sdvo_lvds_fixed_mode =
+   struct drm_display_mode *fixed_mode =
drm_mode_duplicate(connector->dev, mode);
+
+   intel_panel_init(_connector->panel,
+fixed_mode, NULL);
break;
}
}
 
-   if (!intel_sdvo->sdvo_lvds_fixed_mode)
+   if (!intel_connector->panel.fixed_mode)
goto err;
 
return true;
-- 
2.16.4


[Intel-gfx] ✗ Fi.CI.IGT: failure for Per context dynamic (sub)slice power-gating (rev4)

2018-09-17 Thread Patchwork
== Series Details ==

Series: Per context dynamic (sub)slice power-gating (rev4)
URL   : https://patchwork.freedesktop.org/series/48194/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4833_full -> Patchwork_10203_full =

== Summary - FAILURE ==

  Serious unknown changes coming with Patchwork_10203_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_10203_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in 
Patchwork_10203_full:

  === IGT changes ===

 Possible regressions 

igt@gem_ctx_param@invalid-param-get:
  shard-apl:  PASS -> FAIL
  shard-glk:  PASS -> FAIL
  shard-snb:  PASS -> FAIL
  shard-hsw:  PASS -> FAIL
  shard-kbl:  PASS -> FAIL


 Warnings 

igt@kms_vblank@pipe-b-query-forked-hang:
  shard-snb:  PASS -> SKIP +1


== Known issues ==

  Here are the changes found in Patchwork_10203_full that come from known 
issues:

  === IGT changes ===

 Issues hit 

igt@gem_ppgtt@blt-vs-render-ctxn:
  shard-kbl:  PASS -> INCOMPLETE (fdo#106023, fdo#103665)

igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
  shard-apl:  PASS -> DMESG-WARN (fdo#107956)

igt@perf_pmu@init-sema-vcs1:
  shard-snb:  PASS -> INCOMPLETE (fdo#105411)


 Possible fixes 

igt@kms_frontbuffer_tracking@fbc-stridechange:
  shard-glk:  FAIL (fdo#103167) -> PASS

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS

igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
  shard-kbl:  INCOMPLETE (fdo#103665) -> PASS


  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4833 -> Patchwork_10203

  CI_DRM_4833: 75bb460b367a614d10b0fba220143bee42657d7e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4644: 0b59bb3231ab481959528c5c7b3a98762772e1b0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10203: 00297a7d4c51196e972eba87810c64b51aac6f05 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10203/shards.html
___
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 v14 2/2] tests/gem_ctx_sseu: Dynamic (sub)slice programming tests

2018-09-17 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-09-17 12:28:12)
> From: Lionel Landwerlin 
> 
> Verify that the per-context dynamic SSEU uAPI works as expected.
> 
> To achieve that, in the absence of a better mechamism, we read the value
> of PWR_CLK_STATE register, or use MI_SET_PREDICATE on platforms before
> Cannonlake.
> 
> This register is written to by the GPU on context restore so this way
> we verify i915 is correctly updating the context image in all
> circumstances.
> 
> v2: Add subslice tests (Lionel)
> Use MI_SET_PREDICATE for further verification when available (Lionel)
> 
> v3: Rename to gem_ctx_rpcs (Lionel)
> 
> v4: Update kernel API (Lionel)
> Add 0 value test (Lionel)
> Exercise invalid values (Lionel)
> 
> v5: Add perf tests (Lionel)
> 
> v6: Add new sysfs entry tests (Lionel)
> 
> v7: Test rsvd fields
> Update for kernel series changes
> 
> v8: Drop test_no_sseu_support() test (Kelvin)
> Drop drm_intel_*() apis (Chris)
> 
> v9: by Chris:
> Drop all do_ioctl/do_ioctl_err()
> Use gem_context_[gs]et_param()
> Use gem_read() instead of mapping memory
> by Lionel:
> Test dynamic sseu on/off more
> 
> Tvrtko Ursulin:
> 
> v10:
>  * Various style tweaks and refactorings.
>  * New test coverage.
> 
> v11:
>  * Change platform support to just Gen11.
>  * Simplify availability test. (Chris Wilson)
>  * More invalid pointer tests. (Chris Wilson)
> 
> v12:
>  * Fix MAP_FIXED use (doh!).
>  * Fix get/set copy errors.
>  * Drop supported platform test. (Chris Wilson)
>  * Add mmap__gtt test. (Chris Wilson)
> 
> v13:
>  * Commit message tweaks.
>  * Added reset/hang/suspend tests. (Chris Wilson)
>  * Assert spinner is busy. (Chris Wilson)
>  * Remove some more ABI assumptions. (Chris Wilson)
> 
> v14:
>  * Use default resume time. (Chris Wilson)
>  * Trigger hang after rpcs read batch has been submitted. (Chris Wilson)
> 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Tvrtko Ursulin 

I can't think of any other mechanism that could interfere with ctx-sseu
that isn't being tested,
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for Per context dynamic (sub)slice power-gating (rev4)

2018-09-17 Thread Patchwork
== Series Details ==

Series: Per context dynamic (sub)slice power-gating (rev4)
URL   : https://patchwork.freedesktop.org/series/48194/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4833 -> Patchwork_10203 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/48194/revisions/4/mbox/

== Known issues ==

  Here are the changes found in Patchwork_10203 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-skl-caroline:NOTRUN -> INCOMPLETE (fdo#107556, fdo#104108)

igt@kms_frontbuffer_tracking@basic:
  fi-hsw-peppy:   PASS -> DMESG-WARN (fdo#102614)

igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
  fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362)

igt@kms_psr@primary_mmap_gtt:
  {fi-cnl-u}: NOTRUN -> FAIL (fdo#107383) +3


 Possible fixes 

igt@drv_module_reload@basic-reload:
  fi-blb-e6850:   INCOMPLETE (fdo#107718) -> PASS

igt@drv_selftest@live_hangcheck:
  fi-glk-j4005:   INCOMPLETE (k.org#198133, fdo#103359) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-icl-u:   INCOMPLETE (fdo#107713) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   DMESG-FAIL (fdo#103713) -> PASS

igt@kms_psr@primary_page_flip:
  fi-kbl-r:   FAIL (fdo#107336) -> PASS

igt@kms_setmode@basic-clone-single-crtc:
  fi-snb-2520m:   DMESG-WARN (fdo#103713) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108
  fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
  fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556
  fdo#107713 https://bugs.freedesktop.org/show_bug.cgi?id=107713
  fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (46 -> 44) ==

  Additional (2): fi-cnl-u fi-skl-caroline 
  Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4833 -> Patchwork_10203

  CI_DRM_4833: 75bb460b367a614d10b0fba220143bee42657d7e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4644: 0b59bb3231ab481959528c5c7b3a98762772e1b0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10203: 00297a7d4c51196e972eba87810c64b51aac6f05 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

00297a7d4c51 drm/i915/icl: Support co-existence between per-context SSEU and OA
f6f383926f56 drm/i915: Expose RPCS (SSEU) configuration to userspace
6c15d4d43452 drm/i915: Add timeline barrier support
15ae17fc2bb0 drm/i915/perf: lock powergating configuration to default when 
active
275b17e9ba45 drm/i915: Record the sseu configuration per-context & engine
d32c1a36efbb drm/i915/execlists: Move RPCS setup to context pin

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10203/issues.html
___
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/perf: lock powergating configuration to default when active

2018-09-17 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-09-17 12:30:55)
> From: Lionel Landwerlin 
> 
> If some of the contexts submitting workloads to the GPU have been
> configured to shutdown slices/subslices, we might loose the NOA
> configurations written in the NOA muxes.
> 
> One possible solution to this problem is to reprogram the NOA muxes
> when we switch to a new context. We initially tried this in the
> workaround batchbuffer but some concerns where raised about the cost
> of reprogramming at every context switch. This solution is also not
> without consequences from the userspace point of view. Reprogramming
> of the muxes can only happen once the powergating configuration has
> changed (which happens after context switch). This means for a window
> of time during the recording, counters recorded by the OA unit might
> be invalid. This requires userspace dealing with OA reports to discard
> the invalid values.
> 
> Minimizing the reprogramming could be implemented by tracking of the
> last programmed configuration somewhere in GGTT and use MI_PREDICATE
> to discard some of the programming commands, but the command streamer
> would still have to parse all the MI_LRI instructions in the
> workaround batchbuffer.
> 
> Another solution, which this change implements, is to simply disregard
> the user requested configuration for the period of time when i915/perf
> is active. There is no known issue with this apart from a performance
> penality for some media workloads that benefit from running on a
> partially powergated GPU. We already prevent RC6 from affecting the
> programming so it doesn't sound completely unreasonable to hold on
> powergating for the same reason.
> 
> v2: Leave RPCS programming in intel_lrc.c (Lionel)
> 
> v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
> More to_intel_context() (Tvrtko)
> s/dev_priv/i915/ (Tvrtko)
> 
> Tvrtko Ursulin:
> 
> v4:
>  * Rebase for make_rpcs changes.
> 
> v5:
>  * Apply OA restriction from make_rpcs directly.
> 
> v6:
>  * Rebase for context image setup changes.
> 
> v7:
>  * Move stream assignment before metric enable.
> 
> v8:
>  * Rebase.
> 
> Signed-off-by: Lionel Landwerlin 
> Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace

2018-09-17 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-09-17 12:30:57)
> From: Tvrtko Ursulin 
> 
> We want to allow userspace to reconfigure the subslice configuration for
> its own use case. To do so, we expose a context parameter to allow
> adjustment of the RPCS register stored within the context image (and
> currently not accessible via LRI). If the context is adjusted before
> first use, the adjustment is for "free"; otherwise if the context is
> active we flush the context off the GPU (stalling all users) and forcing
> the GPU to save the context to memory where we can modify it and so
> ensure that the register is reloaded on next execution.
> 
> The overhead of managing additional EU subslices can be significant,
> especially in multi-context workloads. Non-GPGPU contexts should
> preferably disable the subslices it is not using, and others should
> fine-tune the number to match their workload.
> 
> We expose complete control over the RPCS register, allowing
> configuration of slice/subslice, via masks packed into a u64 for
> simplicity. For example,
> 
> struct drm_i915_gem_context_param arg;
> struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
> .instance = 0, };
> 
> memset(, 0, sizeof(arg));
> arg.ctx_id = ctx;
> arg.param = I915_CONTEXT_PARAM_SSEU;
> arg.value = (uintptr_t) 
> if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
> sseu.packed.subslice_mask = 0;
> 
> drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
> }
> 
> could be used to disable all subslices where supported.
> 
> v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)
> 
> v3: Add ability to program this per engine (Chris)
> 
> v4: Move most get_sseu() into i915_gem_context.c (Lionel)
> 
> v5: Validate sseu configuration against the device's capabilities (Lionel)
> 
> v6: Change context powergating settings through MI_SDM on kernel context 
> (Chris)
> 
> v7: Synchronize the requests following a powergating setting change using a 
> global
> dependency (Chris)
> Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
> Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)
> 
> v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
> s/dev_priv/i915/ (Tvrtko)
> Change uapi class/instance fields to u16 (Tvrtko)
> Bump mask fields to 64bits (Lionel)
> Don't return EPERM when dynamic sseu is disabled (Tvrtko)
> 
> v9: Import context image into kernel context's ppgtt only when
> reconfiguring powergated slice/subslices (Chris)
> Use aliasing ppgtt when needed (Michel)
> 
> Tvrtko Ursulin:
> 
> v10:
>  * Update for upstream changes.
>  * Request submit needs a RPM reference.
>  * Reject on !FULL_PPGTT for simplicity.
>  * Pull out get/set param to helpers for readability and less indent.
>  * Use i915_request_await_dma_fence in add_global_barrier to skip waits
>on the same timeline and avoid GEM_BUG_ON.
>  * No need to explicitly assign a NULL pointer to engine in legacy mode.
>  * No need to move gen8_make_rpcs up.
>  * Factored out global barrier as prep patch.
>  * Allow to only CAP_SYS_ADMIN if !Gen11.
> 
> v11:
>  * Remove engine vfunc in favour of local helper. (Chris Wilson)
>  * Stop retiring requests before updates since it is not needed
>(Chris Wilson)
>  * Implement direct CPU update path for idle contexts. (Chris Wilson)
>  * Left side dependency needs only be on the same context timeline.
>(Chris Wilson)
>  * It is sufficient to order the timeline. (Chris Wilson)
>  * Reject !RCS configuration attempts with -ENODEV for now.
> 
> v12:
>  * Rebase for make_rpcs.
> 
> v13:
>  * Centralize SSEU normalization to make_rpcs.
>  * Type width checking (uAPI <-> implementation).
>  * Gen11 restrictions uAPI checks.
>  * Gen11 subslice count differences handling.
>  Chris Wilson:
>  * args->size handling fixes.
>  * Update context image from GGTT.
>  * Postpone context image update to pinning.
>  * Use i915_gem_active_raw instead of last_request_on_engine.
> 
> v14:
>  * Add activity tracker on intel_context to fix the lifetime issues
>and simplify the code. (Chris Wilson)
> 
> v15:
>  * Fix context pin leak if no space in ring by simplifying the
>context pinning sequence.
> 
> v16:
>  * Rebase for context get/set param locking changes.
>  * Just -ENODEV on !Gen11. (Joonas)
> 
> v17:
>  * Fix one Gen11 subslice enablement rule.
>  * Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
> Issue: https://github.com/intel/media-driver/issues/267
> Signed-off-by: Chris Wilson 
> Signed-off-by: Lionel Landwerlin 
> Cc: Dmitry Rogozhkin 
> Cc: Tvrtko Ursulin 
> Cc: Zhipeng Gong 
> Cc: Joonas Lahtinen 
> Signed-off-by: Tvrtko Ursulin 
> Reviewed-by: 

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per context dynamic (sub)slice power-gating (rev4)

2018-09-17 Thread Patchwork
== Series Details ==

Series: Per context dynamic (sub)slice power-gating (rev4)
URL   : https://patchwork.freedesktop.org/series/48194/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/execlists: Move RPCS setup to context pin
Okay!

Commit: drm/i915: Record the sseu configuration per-context & engine
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3718:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3732:16: warning: expression 
using sizeof(void)

Commit: drm/i915/perf: lock powergating configuration to default when active
Okay!

Commit: drm/i915: Add timeline barrier support
Okay!

Commit: drm/i915: Expose RPCS (SSEU) configuration to userspace
+drivers/gpu/drm/i915/intel_lrc.c:2562:25: warning: expression using 
sizeof(void)

Commit: drm/i915/icl: Support co-existence between per-context SSEU and OA
Okay!

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


Re: [Intel-gfx] [PATCH 1/6] drm/i915/execlists: Move RPCS setup to context pin

2018-09-17 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-09-17 12:30:53)
> From: Tvrtko Ursulin 
> 
> Configuring RPCS in context image just before pin is sufficient and will
> come extra handy in one of the following patches.
> 
> v2:
>  * Split image setup a bit differently. (Chris Wilson)
> 
> v3:
>  * Update context image after reset as well - otherwise the application
>of pinned default state clears the RPCS.
> 
> v4:
>  * Use local variable throughout the function. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 
> Suggested-by: Chris Wilson 
> Cc: Chris Wilson 
> Reviewed-by: Chris Wilson  # v2

> @@ -1955,14 +1971,14 @@ static void execlists_reset(struct intel_engine_cs 
> *engine,
>engine->pinned_default_state + LRC_STATE_PN * 
> PAGE_SIZE,
>engine->context_size - PAGE_SIZE);
> }
> -   execlists_init_reg_state(regs,
> -request->gem_context, engine, request->ring);
>  
> /* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
> -   regs[CTX_RING_BUFFER_START + 1] = 
> i915_ggtt_offset(request->ring->vma);
> -
> request->ring->head = intel_ring_wrap(request->ring, 
> request->postfix);
> -   regs[CTX_RING_HEAD + 1] = request->ring->head;
> +
> +   execlists_init_reg_state(regs, request->gem_context, engine,
> +request->ring);
> +
> +   __execlists_update_reg_state(engine, request->hw_context);

Probably need to reinforce the comments that the context state after the
guilty reset is our arbitrary defaults and not the state userspace
expects.

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


[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per context dynamic (sub)slice power-gating (rev4)

2018-09-17 Thread Patchwork
== Series Details ==

Series: Per context dynamic (sub)slice power-gating (rev4)
URL   : https://patchwork.freedesktop.org/series/48194/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
d32c1a36efbb drm/i915/execlists: Move RPCS setup to context pin
275b17e9ba45 drm/i915: Record the sseu configuration per-context & engine
15ae17fc2bb0 drm/i915/perf: lock powergating configuration to default when 
active
6c15d4d43452 drm/i915: Add timeline barrier support
f6f383926f56 drm/i915: Expose RPCS (SSEU) configuration to userspace
-:40: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#40: 
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)

total: 0 errors, 1 warnings, 0 checks, 456 lines checked
00297a7d4c51 drm/i915/icl: Support co-existence between per-context SSEU and OA

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


[Intel-gfx] ✓ Fi.CI.IGT: success for ICELAKE DSI DRIVER (rev6)

2018-09-17 Thread Patchwork
== Series Details ==

Series: ICELAKE DSI DRIVER (rev6)
URL   : https://patchwork.freedesktop.org/series/44823/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4833_full -> Patchwork_10202_full =

== Summary - SUCCESS ==

  No regressions found.

  

== Known issues ==

  Here are the changes found in Patchwork_10202_full that come from known 
issues:

  === IGT changes ===

 Issues hit 

igt@drv_suspend@shrink:
  shard-apl:  PASS -> INCOMPLETE (fdo#106886, fdo#103927)

igt@gem_pipe_control_store_loop@reused-buffer:
  shard-glk:  PASS -> INCOMPLETE (k.org#198133, fdo#103359)

igt@gem_ppgtt@blt-vs-render-ctxn:
  shard-kbl:  PASS -> INCOMPLETE (fdo#106023, fdo#103665)

igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
  shard-apl:  PASS -> DMESG-WARN (fdo#107956)

igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
  shard-glk:  PASS -> FAIL (fdo#105363)


 Possible fixes 

igt@kms_busy@extended-pageflip-hang-newfb-render-a:
  shard-glk:  DMESG-WARN (fdo#107956) -> PASS

igt@kms_frontbuffer_tracking@fbc-stridechange:
  shard-glk:  FAIL (fdo#103167) -> PASS

igt@kms_setmode@basic:
  shard-kbl:  FAIL (fdo#99912) -> PASS


  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4833 -> Patchwork_10202

  CI_DRM_4833: 75bb460b367a614d10b0fba220143bee42657d7e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4644: 0b59bb3231ab481959528c5c7b3a98762772e1b0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10202: 15b08802bda983cab8eb17011ec5223b58d2b2f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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


[Intel-gfx] [PATCH 3/6] drm/i915/perf: lock powergating configuration to default when active

2018-09-17 Thread Tvrtko Ursulin
From: Lionel Landwerlin 

If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.

One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.

Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.

Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active. There is no known issue with this apart from a performance
penality for some media workloads that benefit from running on a
partially powergated GPU. We already prevent RC6 from affecting the
programming so it doesn't sound completely unreasonable to hold on
powergating for the same reason.

v2: Leave RPCS programming in intel_lrc.c (Lionel)

v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)

Tvrtko Ursulin:

v4:
 * Rebase for make_rpcs changes.

v5:
 * Apply OA restriction from make_rpcs directly.

v6:
 * Rebase for context image setup changes.

v7:
 * Move stream assignment before metric enable.

v8:
 * Rebase.

Signed-off-by: Lionel Landwerlin 
Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_perf.c | 13 +
 drivers/gpu/drm/i915/intel_lrc.c | 31 ---
 drivers/gpu/drm/i915/intel_lrc.h |  2 ++
 3 files changed, 31 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 664b96bb65a3..46ddd1913fee 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1677,6 +1677,11 @@ static void gen8_update_reg_state_unlocked(struct 
i915_gem_context *ctx,
 
CTX_REG(reg_state, state_offset, flex_regs[i], value);
}
+
+   CTX_REG(reg_state, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
+   gen8_make_rpcs(dev_priv,
+  _intel_context(ctx,
+dev_priv->engine[RCS])->sseu));
 }
 
 /*
@@ -2092,6 +2097,9 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
if (ret)
goto err_lock;
 
+   stream->ops = _oa_stream_ops;
+   dev_priv->perf.oa.exclusive_stream = stream;
+
ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv,
  stream->oa_config);
if (ret) {
@@ -2099,15 +2107,12 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
goto err_enable;
}
 
-   stream->ops = _oa_stream_ops;
-
-   dev_priv->perf.oa.exclusive_stream = stream;
-
mutex_unlock(_priv->drm.struct_mutex);
 
return 0;
 
 err_enable:
+   dev_priv->perf.oa.exclusive_stream = NULL;
dev_priv->perf.oa.ops.disable_metric_set(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1491032b675b..cf2e0848fa55 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1305,9 +1305,6 @@ static int __context_pin(struct i915_gem_context *ctx, 
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
 }
 
-static u32
-make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
-
 static void
 __execlists_update_reg_state(struct intel_engine_cs *engine,
 struct intel_context *ce)
@@ -1321,8 +1318,8 @@ __execlists_update_reg_state(struct intel_engine_cs 
*engine,
 
/* RPCS */
if (engine->class == RENDER_CLASS)
-   regs[CTX_R_PWR_CLK_STATE + 1] = make_rpcs(engine->i915,
- >sseu);
+   regs[CTX_R_PWR_CLK_STATE + 1] = gen8_make_rpcs(engine->i915,
+  >sseu);
 }
 
 static struct intel_context *
@@ -2507,13 +2504,12 @@ int logical_xcs_ring_init(struct intel_engine_cs 
*engine)
return logical_ring_init(engine);
 }
 
-static u32
-make_rpcs(struct drm_i915_private *i915, struct 

[Intel-gfx] [PATCH 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace

2018-09-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

We want to allow userspace to reconfigure the subslice configuration for
its own use case. To do so, we expose a context parameter to allow
adjustment of the RPCS register stored within the context image (and
currently not accessible via LRI). If the context is adjusted before
first use, the adjustment is for "free"; otherwise if the context is
active we flush the context off the GPU (stalling all users) and forcing
the GPU to save the context to memory where we can modify it and so
ensure that the register is reloaded on next execution.

The overhead of managing additional EU subslices can be significant,
especially in multi-context workloads. Non-GPGPU contexts should
preferably disable the subslices it is not using, and others should
fine-tune the number to match their workload.

We expose complete control over the RPCS register, allowing
configuration of slice/subslice, via masks packed into a u64 for
simplicity. For example,

struct drm_i915_gem_context_param arg;
struct drm_i915_gem_context_param_sseu sseu = { .class = 0,
.instance = 0, };

memset(, 0, sizeof(arg));
arg.ctx_id = ctx;
arg.param = I915_CONTEXT_PARAM_SSEU;
arg.value = (uintptr_t) 
if (drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_GETPARAM, ) == 0) {
sseu.packed.subslice_mask = 0;

drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, );
}

could be used to disable all subslices where supported.

v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu() (Lionel)

v3: Add ability to program this per engine (Chris)

v4: Move most get_sseu() into i915_gem_context.c (Lionel)

v5: Validate sseu configuration against the device's capabilities (Lionel)

v6: Change context powergating settings through MI_SDM on kernel context (Chris)

v7: Synchronize the requests following a powergating setting change using a 
global
dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users (Lionel/Tvrtko)

v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)

v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)

Tvrtko Ursulin:

v10:
 * Update for upstream changes.
 * Request submit needs a RPM reference.
 * Reject on !FULL_PPGTT for simplicity.
 * Pull out get/set param to helpers for readability and less indent.
 * Use i915_request_await_dma_fence in add_global_barrier to skip waits
   on the same timeline and avoid GEM_BUG_ON.
 * No need to explicitly assign a NULL pointer to engine in legacy mode.
 * No need to move gen8_make_rpcs up.
 * Factored out global barrier as prep patch.
 * Allow to only CAP_SYS_ADMIN if !Gen11.

v11:
 * Remove engine vfunc in favour of local helper. (Chris Wilson)
 * Stop retiring requests before updates since it is not needed
   (Chris Wilson)
 * Implement direct CPU update path for idle contexts. (Chris Wilson)
 * Left side dependency needs only be on the same context timeline.
   (Chris Wilson)
 * It is sufficient to order the timeline. (Chris Wilson)
 * Reject !RCS configuration attempts with -ENODEV for now.

v12:
 * Rebase for make_rpcs.

v13:
 * Centralize SSEU normalization to make_rpcs.
 * Type width checking (uAPI <-> implementation).
 * Gen11 restrictions uAPI checks.
 * Gen11 subslice count differences handling.
 Chris Wilson:
 * args->size handling fixes.
 * Update context image from GGTT.
 * Postpone context image update to pinning.
 * Use i915_gem_active_raw instead of last_request_on_engine.

v14:
 * Add activity tracker on intel_context to fix the lifetime issues
   and simplify the code. (Chris Wilson)

v15:
 * Fix context pin leak if no space in ring by simplifying the
   context pinning sequence.

v16:
 * Rebase for context get/set param locking changes.
 * Just -ENODEV on !Gen11. (Joonas)

v17:
 * Fix one Gen11 subslice enablement rule.
 * Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
Cc: Dmitry Rogozhkin 
Cc: Tvrtko Ursulin 
Cc: Zhipeng Gong 
Cc: Joonas Lahtinen 
Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson  # v15
---
 drivers/gpu/drm/i915/i915_gem_context.c | 318 +++-
 drivers/gpu/drm/i915/i915_gem_context.h |   6 +
 drivers/gpu/drm/i915/intel_lrc.c|   4 +-
 include/uapi/drm/i915_drm.h |  43 
 4 files changed, 368 insertions(+), 3 deletions(-)


[Intel-gfx] [PATCH 6/6] drm/i915/icl: Support co-existence between per-context SSEU and OA

2018-09-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

When OA is active we want to lock the powergating configuration, but on
Icelake, users like the media stack will have issues if we lock to the
full device configuration.

Instead lock to a subset of (sub)slices which are currently a known
working configuration for all users.

v2:
 * Fix commit message spelling.

Signed-off-by: Tvrtko Ursulin 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b5603e977a3f..cded1f1d9ec2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2521,13 +2521,28 @@ u32 gen8_make_rpcs(struct drm_i915_private *i915, 
struct intel_sseu *req_sseu)
 
/*
 * If i915/perf is active, we want a stable powergating configuration
-* on the system. The most natural configuration to take in that case
-* is the default (i.e maximum the hardware can do).
+* on the system.
+*
+* We could choose full enablement, but on ICL we know there are use
+* cases which disable slices for functional, apart for performance
+* reasons. So in this case we select a known stable subset.
 */
-   if (unlikely(i915->perf.oa.exclusive_stream))
-   ctx_sseu = intel_device_default_sseu(i915);
-   else
+   if (!i915->perf.oa.exclusive_stream) {
ctx_sseu = *req_sseu;
+   } else {
+   ctx_sseu = intel_device_default_sseu(i915);
+
+   if (IS_GEN11(i915)) {
+   /*
+* We only need subslice count so it doesn't matter
+* which ones we select - just turn of low bits in the
+* amount of half of all available subslices per slice.
+*/
+   ctx_sseu.subslice_mask =
+   ~(~0 << (hweight8(ctx_sseu.subslice_mask) / 2));
+   ctx_sseu.slice_mask = 0x1;
+   }
+   }
 
slices = hweight8(ctx_sseu.slice_mask);
subslices = hweight8(ctx_sseu.subslice_mask);
-- 
2.17.1

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


[Intel-gfx] [PATCH 4/6] drm/i915: Add timeline barrier support

2018-09-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Timeline barrier allows serialization between different timelines.

After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically gets
cleared and things continue as normal.

This facility will be used by the upcoming context SSEU code.

v2:
 * Assert barrier has been retired on timeline_fini. (Chris Wilson)
 * Fix mock_timeline.

Signed-off-by: Tvrtko Ursulin 
Suggested-by: Chris Wilson 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_request.c   | 13 +
 drivers/gpu/drm/i915/i915_timeline.c  |  3 +++
 drivers/gpu/drm/i915/i915_timeline.h  | 27 +++
 .../gpu/drm/i915/selftests/mock_timeline.c|  2 ++
 4 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index a492385b2089..76fc80330c85 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -644,6 +644,15 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
return NOTIFY_DONE;
 }
 
+static int add_timeline_barrier(struct i915_request *rq)
+{
+   struct i915_request *barrier =
+   i915_gem_active_raw(>timeline->barrier,
+   >i915->drm.struct_mutex);
+
+   return barrier ? i915_request_await_dma_fence(rq, >fence) : 0;
+}
+
 /**
  * i915_request_alloc - allocate a request structure
  *
@@ -808,6 +817,10 @@ i915_request_alloc(struct intel_engine_cs *engine, struct 
i915_gem_context *ctx)
 */
rq->head = rq->ring->emit;
 
+   ret = add_timeline_barrier(rq);
+   if (ret)
+   goto err_unwind;
+
/* Unconditionally invalidate GPU caches and TLBs. */
ret = engine->emit_flush(rq, EMIT_INVALIDATE);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_timeline.c 
b/drivers/gpu/drm/i915/i915_timeline.c
index 4667cc08c416..5a87c5bd5154 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -37,6 +37,8 @@ void i915_timeline_init(struct drm_i915_private *i915,
INIT_LIST_HEAD(>requests);
 
i915_syncmap_init(>sync);
+
+   init_request_active(>barrier, NULL);
 }
 
 /**
@@ -69,6 +71,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
 void i915_timeline_fini(struct i915_timeline *timeline)
 {
GEM_BUG_ON(!list_empty(>requests));
+   GEM_BUG_ON(i915_gem_active_isset(>barrier));
 
i915_syncmap_free(>sync);
 
diff --git a/drivers/gpu/drm/i915/i915_timeline.h 
b/drivers/gpu/drm/i915/i915_timeline.h
index a2c2c3ab5fb0..c8526ab44dbc 100644
--- a/drivers/gpu/drm/i915/i915_timeline.h
+++ b/drivers/gpu/drm/i915/i915_timeline.h
@@ -72,6 +72,16 @@ struct i915_timeline {
 */
u32 global_sync[I915_NUM_ENGINES];
 
+   /**
+* Barrier provides the ability to serialize ordering between different
+* timelines.
+*
+* Users can call i915_timeline_set_barrier which will make all
+* subsequent submissions be executed only after this barrier has been
+* completed.
+*/
+   struct i915_gem_active barrier;
+
struct list_head link;
const char *name;
 
@@ -125,4 +135,21 @@ static inline bool i915_timeline_sync_is_later(struct 
i915_timeline *tl,
 
 void i915_timelines_park(struct drm_i915_private *i915);
 
+/**
+ * i915_timeline_set_barrier - orders submission between different timelines
+ * @timeline: timeline to set the barrier on
+ * @rq: request after which new submissions can proceed
+ *
+ * Sets the passed in request as the serialization point for all subsequent
+ * submissions on @timeline. Subsequent requests will not be submitted to GPU
+ * until the barrier has been completed.
+ */
+static inline void
+i915_timeline_set_barrier(struct i915_timeline *timeline,
+ struct i915_request *rq)
+{
+   GEM_BUG_ON(timeline->fence_context == rq->timeline->fence_context);
+   i915_gem_active_set(>barrier, rq);
+}
+
 #endif
diff --git a/drivers/gpu/drm/i915/selftests/mock_timeline.c 
b/drivers/gpu/drm/i915/selftests/mock_timeline.c
index dcf3b16f5a07..a718b64c988e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/mock_timeline.c
@@ -19,6 +19,8 @@ void mock_timeline_init(struct i915_timeline *timeline, u64 
context)
 
i915_syncmap_init(>sync);
 
+   init_request_active(>barrier, NULL);
+
INIT_LIST_HEAD(>link);
 }
 
-- 
2.17.1

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


[Intel-gfx] [PATCH v13 0/6] Per context dynamic (sub)slice power-gating

2018-09-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Fix for Icelake input validation logic and more review feedback.

Lionel Landwerlin (2):
  drm/i915: Record the sseu configuration per-context & engine
  drm/i915/perf: lock powergating configuration to default when active

Tvrtko Ursulin (4):
  drm/i915/execlists: Move RPCS setup to context pin
  drm/i915: Add timeline barrier support
  drm/i915: Expose RPCS (SSEU) configuration to userspace
  drm/i915/icl: Support co-existence between per-context SSEU and OA

 drivers/gpu/drm/i915/i915_drv.h   |  14 +
 drivers/gpu/drm/i915/i915_gem_context.c   | 320 +-
 drivers/gpu/drm/i915/i915_gem_context.h   |  10 +
 drivers/gpu/drm/i915/i915_perf.c  |  13 +-
 drivers/gpu/drm/i915/i915_request.c   |  13 +
 drivers/gpu/drm/i915/i915_request.h   |  10 +
 drivers/gpu/drm/i915/i915_timeline.c  |   3 +
 drivers/gpu/drm/i915/i915_timeline.h  |  27 ++
 drivers/gpu/drm/i915/intel_lrc.c  | 100 --
 drivers/gpu/drm/i915/intel_lrc.h  |   2 +
 .../gpu/drm/i915/selftests/mock_timeline.c|   2 +
 include/uapi/drm/i915_drm.h   |  43 +++
 12 files changed, 520 insertions(+), 37 deletions(-)

-- 
2.17.1

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


[Intel-gfx] [PATCH 1/6] drm/i915/execlists: Move RPCS setup to context pin

2018-09-17 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

Configuring RPCS in context image just before pin is sufficient and will
come extra handy in one of the following patches.

v2:
 * Split image setup a bit differently. (Chris Wilson)

v3:
 * Update context image after reset as well - otherwise the application
   of pinned default state clears the RPCS.

v4:
 * Use local variable throughout the function. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Suggested-by: Chris Wilson 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson  # v2
---
 drivers/gpu/drm/i915/intel_lrc.c | 45 
 1 file changed, 28 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a51be16ddaac..54446b6aeb7a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1305,6 +1305,24 @@ static int __context_pin(struct i915_gem_context *ctx, 
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
 }
 
+static u32 make_rpcs(struct drm_i915_private *dev_priv);
+
+static void
+__execlists_update_reg_state(struct intel_engine_cs *engine,
+struct intel_context *ce)
+{
+   u32 *regs = ce->lrc_reg_state;
+   struct intel_ring *ring = ce->ring;
+
+   regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(ring->vma);
+   regs[CTX_RING_HEAD + 1] = ring->head;
+   regs[CTX_RING_TAIL + 1] = ring->tail;
+
+   /* RPCS */
+   if (engine->class == RENDER_CLASS)
+   regs[CTX_R_PWR_CLK_STATE + 1] = make_rpcs(engine->i915);
+}
+
 static struct intel_context *
 __execlists_context_pin(struct intel_engine_cs *engine,
struct i915_gem_context *ctx,
@@ -1343,10 +1361,8 @@ __execlists_context_pin(struct intel_engine_cs *engine,
GEM_BUG_ON(!intel_ring_offset_valid(ce->ring, ce->ring->head));
 
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
-   ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
-   i915_ggtt_offset(ce->ring->vma);
-   ce->lrc_reg_state[CTX_RING_HEAD + 1] = ce->ring->head;
-   ce->lrc_reg_state[CTX_RING_TAIL + 1] = ce->ring->tail;
+
+   __execlists_update_reg_state(engine, ce);
 
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
@@ -1955,14 +1971,14 @@ static void execlists_reset(struct intel_engine_cs 
*engine,
   engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
   engine->context_size - PAGE_SIZE);
}
-   execlists_init_reg_state(regs,
-request->gem_context, engine, request->ring);
 
/* Move the RING_HEAD onto the breadcrumb, past the hanging batch */
-   regs[CTX_RING_BUFFER_START + 1] = i915_ggtt_offset(request->ring->vma);
-
request->ring->head = intel_ring_wrap(request->ring, request->postfix);
-   regs[CTX_RING_HEAD + 1] = request->ring->head;
+
+   execlists_init_reg_state(regs, request->gem_context, engine,
+request->ring);
+
+   __execlists_update_reg_state(engine, request->hw_context);
 
intel_ring_update_space(request->ring);
 
@@ -2710,8 +2726,7 @@ static void execlists_init_reg_state(u32 *regs,
 
if (rcs) {
regs[CTX_LRI_HEADER_2] = MI_LOAD_REGISTER_IMM(1);
-   CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE,
-   make_rpcs(dev_priv));
+   CTX_REG(regs, CTX_R_PWR_CLK_STATE, GEN8_R_PWR_CLK_STATE, 0);
 
i915_oa_init_reg_state(engine, ctx, regs);
}
@@ -2872,12 +2887,8 @@ void intel_lr_context_resume(struct drm_i915_private 
*i915)
 
intel_ring_reset(ce->ring, 0);
 
-   if (ce->pin_count) { /* otherwise done in context_pin */
-   u32 *regs = ce->lrc_reg_state;
-
-   regs[CTX_RING_HEAD + 1] = ce->ring->head;
-   regs[CTX_RING_TAIL + 1] = ce->ring->tail;
-   }
+   if (ce->pin_count) /* otherwise done in context_pin */
+   __execlists_update_reg_state(engine, ce);
}
}
 }
-- 
2.17.1

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


[Intel-gfx] [PATCH 2/6] drm/i915: Record the sseu configuration per-context & engine

2018-09-17 Thread Tvrtko Ursulin
From: Lionel Landwerlin 

We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.

v2: record sseu configuration per context & engine (Chris)

v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)

v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)

v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)

v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)

Tvrtko Ursulin:

v7:
 * Pass intel_sseu by pointer instead of value to make_rpcs.
 * Rebase for make_rpcs changes.

v8:
 * Rebase for RPCS edit on pin.

v9:
 * Rebase for context image setup changes.

v10:
 * Rename dev_priv to i915. (Chris Wilson)

v11:
 * Rebase.

Signed-off-by: Chris Wilson 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Tvrtko Ursulin 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h | 14 +++
 drivers/gpu/drm/i915/i915_gem_context.c |  2 ++
 drivers/gpu/drm/i915/i915_gem_context.h |  4 
 drivers/gpu/drm/i915/i915_request.h | 10 
 drivers/gpu/drm/i915/intel_lrc.c| 31 +
 5 files changed, 46 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7d4daa7412f1..6b7ae63e47c3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3479,6 +3479,20 @@ mkwrite_device_info(struct drm_i915_private *dev_priv)
return (struct intel_device_info *)_priv->info;
 }
 
+static inline struct intel_sseu
+intel_device_default_sseu(struct drm_i915_private *i915)
+{
+   const struct sseu_dev_info *sseu = _INFO(i915)->sseu;
+   struct intel_sseu value = {
+   .slice_mask = sseu->slice_mask,
+   .subslice_mask = sseu->subslice_mask[0],
+   .min_eus_per_subslice = sseu->max_eus_per_subslice,
+   .max_eus_per_subslice = sseu->max_eus_per_subslice,
+   };
+
+   return value;
+}
+
 /* modesetting */
 extern void intel_modeset_init_hw(struct drm_device *dev);
 extern int intel_modeset_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index f772593b99ab..0b8cc748648b 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -343,6 +343,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
struct intel_context *ce = >__engine[n];
 
ce->gem_context = ctx;
+   /* Use the whole device by default */
+   ce->sseu = intel_device_default_sseu(dev_priv);
}
 
INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 08165f6a0a84..7510de738b35 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -31,6 +31,7 @@
 
 #include "i915_gem.h"
 #include "i915_scheduler.h"
+#include "intel_device_info.h"
 
 struct pid;
 
@@ -170,6 +171,9 @@ struct i915_gem_context {
int pin_count;
 
const struct intel_context_ops *ops;
+
+   /** sseu: Control eu/slice partitioning */
+   struct intel_sseu sseu;
} __engine[I915_NUM_ENGINES];
 
/** ring_size: size for allocating the per-engine ring buffer */
diff --git a/drivers/gpu/drm/i915/i915_request.h 
b/drivers/gpu/drm/i915/i915_request.h
index 7fa94b024968..3a4be20ea74a 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -39,6 +39,16 @@ struct drm_i915_gem_object;
 struct i915_request;
 struct i915_timeline;
 
+/*
+ * Powergating configuration for a particular (context,engine).
+ */
+struct intel_sseu {
+   u8 slice_mask;
+   u8 subslice_mask;
+   u8 min_eus_per_subslice;
+   u8 max_eus_per_subslice;
+};
+
 struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 54446b6aeb7a..1491032b675b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1305,7 +1305,8 @@ static int __context_pin(struct i915_gem_context *ctx, 
struct i915_vma *vma)
return i915_vma_pin(vma, 0, 0, flags);
 }
 
-static u32 make_rpcs(struct drm_i915_private *dev_priv);
+static u32
+make_rpcs(struct drm_i915_private *i915, struct intel_sseu *ctx_sseu);
 
 static void
 __execlists_update_reg_state(struct intel_engine_cs *engine,
@@ -1320,7 +1321,8 @@ __execlists_update_reg_state(struct intel_engine_cs 
*engine,
 
/* RPCS */
if 

Re: [Intel-gfx] [STABLE v4.14 PATCH] drm/i915: set DP Main Stream Attribute for color range on DDI platforms

2018-09-17 Thread Greg KH
On Fri, Sep 14, 2018 at 04:39:42PM +0300, Jani Nikula wrote:
> commit 6209c285e7a5e68dbcdf8fd2456c6dd68433806b upstream.

Now applied, thanks.

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


[Intel-gfx] [PATCH i-g-t v14 2/2] tests/gem_ctx_sseu: Dynamic (sub)slice programming tests

2018-09-17 Thread Tvrtko Ursulin
From: Lionel Landwerlin 

Verify that the per-context dynamic SSEU uAPI works as expected.

To achieve that, in the absence of a better mechamism, we read the value
of PWR_CLK_STATE register, or use MI_SET_PREDICATE on platforms before
Cannonlake.

This register is written to by the GPU on context restore so this way
we verify i915 is correctly updating the context image in all
circumstances.

v2: Add subslice tests (Lionel)
Use MI_SET_PREDICATE for further verification when available (Lionel)

v3: Rename to gem_ctx_rpcs (Lionel)

v4: Update kernel API (Lionel)
Add 0 value test (Lionel)
Exercise invalid values (Lionel)

v5: Add perf tests (Lionel)

v6: Add new sysfs entry tests (Lionel)

v7: Test rsvd fields
Update for kernel series changes

v8: Drop test_no_sseu_support() test (Kelvin)
Drop drm_intel_*() apis (Chris)

v9: by Chris:
Drop all do_ioctl/do_ioctl_err()
Use gem_context_[gs]et_param()
Use gem_read() instead of mapping memory
by Lionel:
Test dynamic sseu on/off more

Tvrtko Ursulin:

v10:
 * Various style tweaks and refactorings.
 * New test coverage.

v11:
 * Change platform support to just Gen11.
 * Simplify availability test. (Chris Wilson)
 * More invalid pointer tests. (Chris Wilson)

v12:
 * Fix MAP_FIXED use (doh!).
 * Fix get/set copy errors.
 * Drop supported platform test. (Chris Wilson)
 * Add mmap__gtt test. (Chris Wilson)

v13:
 * Commit message tweaks.
 * Added reset/hang/suspend tests. (Chris Wilson)
 * Assert spinner is busy. (Chris Wilson)
 * Remove some more ABI assumptions. (Chris Wilson)

v14:
 * Use default resume time. (Chris Wilson)
 * Trigger hang after rpcs read batch has been submitted. (Chris Wilson)

Signed-off-by: Lionel Landwerlin 
Signed-off-by: Tvrtko Ursulin 
---
 tests/Makefile.am  |1 +
 tests/Makefile.sources |1 +
 tests/gem_ctx_param.c  |4 +-
 tests/gem_ctx_sseu.c   | 1120 
 tests/meson.build  |7 +
 5 files changed, 1132 insertions(+), 1 deletion(-)
 create mode 100644 tests/gem_ctx_sseu.c

diff --git a/tests/Makefile.am b/tests/Makefile.am
index ee5a7c5e83b8..6b67bd2cc17a 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -107,6 +107,7 @@ gem_close_race_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_close_race_LDADD = $(LDADD) -lpthread
 gem_ctx_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_ctx_thrash_LDADD = $(LDADD) -lpthread
+gem_ctx_sseu_LDADD = $(LDADD) $(top_builddir)/lib/libigt_perf.la
 gem_exec_parallel_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
 gem_exec_parallel_LDADD = $(LDADD) -lpthread
 gem_fence_thrash_CFLAGS = $(AM_CFLAGS) $(THREAD_CFLAGS)
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index c84933f1d971..f8f2c8d67d72 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -56,6 +56,7 @@ TESTS_progs = \
gem_ctx_exec \
gem_ctx_isolation \
gem_ctx_param \
+   gem_ctx_sseu \
gem_ctx_switch \
gem_ctx_thrash \
gem_double_irq_loop \
diff --git a/tests/gem_ctx_param.c b/tests/gem_ctx_param.c
index c46fd709b0d7..af1afeaa2f2f 100644
--- a/tests/gem_ctx_param.c
+++ b/tests/gem_ctx_param.c
@@ -294,11 +294,13 @@ igt_main
set_priority(fd);
}
 
+   /* I915_CONTEXT_PARAM_SSEU tests are located in gem_ctx_sseu.c */
+
/* NOTE: This testcase intentionally tests for the next free parameter
 * to catch ABI extensions. Don't "fix" this testcase without adding all
 * the tests for the new param first.
 */
-   arg.param = I915_CONTEXT_PARAM_PRIORITY + 1;
+   arg.param = I915_CONTEXT_PARAM_SSEU + 1;
 
igt_subtest("invalid-param-get") {
arg.ctx_id = ctx;
diff --git a/tests/gem_ctx_sseu.c b/tests/gem_ctx_sseu.c
new file mode 100644
index ..9dde3e457b71
--- /dev/null
+++ b/tests/gem_ctx_sseu.c
@@ -0,0 +1,1120 @@
+/*
+ * Copyright © 2017-2018 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, 

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t v13 2/2] tests/gem_ctx_sseu: Dynamic (sub)slice programming tests

2018-09-17 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-09-17 10:33:47)
> 
> On 14/09/2018 17:17, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-09-14 17:04:38)
> >> +static igt_spin_t *
> >> +__post_set(int fd, unsigned int flags, uint32_t ctx, igt_spin_t *spin,
> >> +  unsigned int expected)
> >> +{
> >> +   bool busy_reset = (flags & TEST_BUSY) &&
> >> + (flags & (TEST_RESET | TEST_HANG));
> >> +
> >> +   if (flags & TEST_RESET)
> >> +   igt_force_gpu_reset(fd);
> >> +   else if (flags & TEST_HANG)
> >> +   gem_sync(fd, spin->handle);
> > 
> > Hmm, in both cases this is before we submit the read/post-sseu batch.
> > 
> > I was thinking more for the hang you would simply opt to not terminate
> > the spinner.
> 
> Okay I can do that as well. Hang will then be processed while we try to 
> pread the rpcs eb result so I think it works.
> 
> > 
> > Being utterly pedantic, we may want to check per-engine resets and
> > device level.
> 
> Isn't the per-engine default, so the hang test flavour would trigger it? 
> And to explicitly ask for whole device we have some debugfs api for it?

i915.reset=2 (default if supported) per-engine
i915.reset=1 global
i915.reset=0 none, will wedge on hang.

Alas no temporary override via debugfs yet. Be my guest :)

> >> +   if (spin && !busy_reset) {
> >> +   igt_assert_eq(read_slice_count_busy(fd, ctx, 0, spin),
> >> + expected);
> >> +   } else {
> >> +   igt_assert_eq(read_slice_count(fd, ctx, 0), expected);
> >> +   }
> >> +
> >> +   igt_assert_eq(read_slice_count(fd, 0, 0), __slice_count__);
> >> +
> >> +   if (spin)
> >> +   igt_spin_batch_free(fd, spin);
> >> +
> >> +   if (flags & TEST_IDLE)
> >> +   igt_drop_caches_set(fd, DROP_RETIRE | DROP_IDLE | 
> >> DROP_ACTIVE);
> >> +
> >> +   if (flags & TEST_SUSPEND) {
> >> +   igt_set_autoresume_delay(5);
> > 
> > Brave. Opting for a faster wakeup than default...
> 
> I think I started with copy paste and then lowered it when testing the 
> test. Is the right thing to omit specifying it?

Yes. The default (15s) should be the conservative minimal required for
all machines to be sure we don't miss the wakeup (or it trigger at the
wrong time and cause -EBUSY). There are a few tests where we know
(e.g. we're waiting on hangcheck) that 15s is not enough.

We might suggest to Tomi to do some trial and error and see if we can
stably reduce it across the board.
 
> >> +   igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
> >> + SUSPEND_TEST_NONE);
> >> +   }
> >> +
> >> +   igt_assert_eq(read_slice_count(fd, ctx, 0), expected);
> >> +   igt_assert_eq(read_slice_count(fd, 0, 0), __slice_count__);
> >> +
> >> +   return NULL;
> >> +}
> > 
> > Overall, nothing else strikes me as being absent.
> > 
> > Oh, one more thing; do we are what state we leave the system in on
> > module unload? So long as the GPU reset clears it we should be ok.
> 
> I don't think it applies when device is off. And on load running the 
> kernel context restores the default full enablement.

That's not strictly true... On module load the kernel context will be
marked with RESTORE_INHIBIT as it is created before the default_state
is. It's the next context to be used that will have the full setup.

I think the reset is good enough as the defaults should be sane (or we
have a w/a to set up sane register state), and once we start using the
device proper all is specified. Needless worry on my part.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.BAT: success for ICELAKE DSI DRIVER (rev6)

2018-09-17 Thread Patchwork
== Series Details ==

Series: ICELAKE DSI DRIVER (rev6)
URL   : https://patchwork.freedesktop.org/series/44823/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4833 -> Patchwork_10202 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: 
https://patchwork.freedesktop.org/api/1.0/series/44823/revisions/6/mbox/

== Known issues ==

  Here are the changes found in Patchwork_10202 that come from known issues:

  === IGT changes ===

 Issues hit 

igt@gem_exec_suspend@basic-s3:
  fi-blb-e6850:   PASS -> INCOMPLETE (fdo#107718)

igt@kms_frontbuffer_tracking@basic:
  fi-byt-clapper: PASS -> FAIL (fdo#103167)

igt@kms_pipe_crc_basic@read-crc-pipe-b:
  fi-byt-clapper: PASS -> FAIL (fdo#107362)

igt@kms_psr@primary_mmap_gtt:
  {fi-cnl-u}: NOTRUN -> FAIL (fdo#107383) +3

igt@kms_psr@primary_page_flip:
  fi-kbl-7560u:   PASS -> FAIL (fdo#107336)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  fi-glk-j4005:   INCOMPLETE (k.org#198133, fdo#103359) -> PASS

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
  fi-icl-u:   INCOMPLETE (fdo#107713) -> PASS

igt@kms_psr@primary_page_flip:
  fi-kbl-r:   FAIL (fdo#107336) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
  fdo#107713 https://bugs.freedesktop.org/show_bug.cgi?id=107713
  fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (46 -> 42) ==

  Additional (1): fi-cnl-u 
  Missing(5): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-snb-2520m 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4833 -> Patchwork_10202

  CI_DRM_4833: 75bb460b367a614d10b0fba220143bee42657d7e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4644: 0b59bb3231ab481959528c5c7b3a98762772e1b0 @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10202: 15b08802bda983cab8eb17011ec5223b58d2b2f6 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

15b08802bda9 drm/i915/icl: Set max return packet size for DSI panel
f2dc51c599ca drm/i915/icl: Define DSI panel programming registers
53c7f89bc2c8 drm/i915/icl: Enable DSI transcoders
d60941c04633 drm/i915/icl: Define TRANS_CONF register for DSI
84150913bbec drm/i915/icl: Configure DSI transcoder timings
931e0ac850e1 drm/i915/icl: Define DSI transcoder timing registers
4ce170f7cb63 drm/i915/icl: Program TRANS_DDI_FUNC_CTL registers
dd8121a8cd3e drm/i915/icl: Define TRANS_DDI_FUNC_CTL DSI registers
26b610a7e8ec drm/i915/icl: Configure DSI transcoders
f93429566bcb drm/i915/icl: Define TRANS_DSI_FUNC_CONF register
3ebb9338c995 drm/i915/icl: Add macros for MMIO of DSI transcoder registers
a849c1a4275d drm/i915/icl: Get DSI transcoder for a given port
8fbbc4ee3420 drm/i915/icl: Program TA_TIMING_PARAM registers
7bd867a46062 drm/i915/icl: Define TA_TIMING_PARAM registers
fc458cdc926d drm/i915/icl: Program DSI clock and data lane timing params
ca0b99a5f68a drm/i915/icl: Define data/clock lanes dphy timing registers
dcc54b5bf339 drm/i915/icl: Program T_INIT_MASTER registers
6800122a52f4 drm/i915/icl: Enable DDI Buffer
a23c4fb75969 drm/i915/icl: DSI vswing programming sequence
e73ace1c09ae drm/i915/icl: Configure lane sequencing of combo phy transmitter

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10202/issues.html
___
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 v13 2/2] tests/gem_ctx_sseu: Dynamic (sub)slice programming tests

2018-09-17 Thread Tvrtko Ursulin


On 14/09/2018 17:17, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-09-14 17:04:38)

+static igt_spin_t *
+__post_set(int fd, unsigned int flags, uint32_t ctx, igt_spin_t *spin,
+  unsigned int expected)
+{
+   bool busy_reset = (flags & TEST_BUSY) &&
+ (flags & (TEST_RESET | TEST_HANG));
+
+   if (flags & TEST_RESET)
+   igt_force_gpu_reset(fd);
+   else if (flags & TEST_HANG)
+   gem_sync(fd, spin->handle);


Hmm, in both cases this is before we submit the read/post-sseu batch.

I was thinking more for the hang you would simply opt to not terminate
the spinner.


Okay I can do that as well. Hang will then be processed while we try to 
pread the rpcs eb result so I think it works.




Being utterly pedantic, we may want to check per-engine resets and
device level.


Isn't the per-engine default, so the hang test flavour would trigger it? 
And to explicitly ask for whole device we have some debugfs api for it?



+   if (spin && !busy_reset) {
+   igt_assert_eq(read_slice_count_busy(fd, ctx, 0, spin),
+ expected);
+   } else {
+   igt_assert_eq(read_slice_count(fd, ctx, 0), expected);
+   }
+
+   igt_assert_eq(read_slice_count(fd, 0, 0), __slice_count__);
+
+   if (spin)
+   igt_spin_batch_free(fd, spin);
+
+   if (flags & TEST_IDLE)
+   igt_drop_caches_set(fd, DROP_RETIRE | DROP_IDLE | DROP_ACTIVE);
+
+   if (flags & TEST_SUSPEND) {
+   igt_set_autoresume_delay(5);


Brave. Opting for a faster wakeup than default...


I think I started with copy paste and then lowered it when testing the 
test. Is the right thing to omit specifying it?



+   igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
+ SUSPEND_TEST_NONE);
+   }
+
+   igt_assert_eq(read_slice_count(fd, ctx, 0), expected);
+   igt_assert_eq(read_slice_count(fd, 0, 0), __slice_count__);
+
+   return NULL;
+}


Overall, nothing else strikes me as being absent.

Oh, one more thing; do we are what state we leave the system in on
module unload? So long as the GPU reset clears it we should be ok.


I don't think it applies when device is off. And on load running the 
kernel context restores the default full enablement.


Regards,

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


Re: [Intel-gfx] [PATCH 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace

2018-09-17 Thread Tvrtko Ursulin


On 14/09/2018 17:28, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-09-14 17:09:31)

+static int
+gen8_modify_rpcs_gpu(struct intel_context *ce,
+struct intel_engine_cs *engine,
+struct intel_sseu sseu)
+{
+   struct drm_i915_private *i915 = engine->i915;
+   struct i915_request *rq, *prev;
+   int ret;
+
+   GEM_BUG_ON(!ce->pin_count);
+
+   lockdep_assert_held(>drm.struct_mutex);
+
+   /* Submitting requests etc needs the hw awake. */
+   intel_runtime_pm_get(i915);
+
+   rq = i915_request_alloc(engine, i915->kernel_context);
+   if (IS_ERR(rq)) {
+   ret = PTR_ERR(rq);
+   goto out_put;
+   }
+
+   ret = gen8_emit_rpcs_config(rq, ce, sseu);
+   if (ret)
+   goto out_add;
+
+   /* Queue this switch after all other activity by this context. */
+   prev = i915_gem_active_raw(>ring->timeline->last_request,
+  >drm.struct_mutex);
+   if (prev && !i915_request_completed(prev))
+   i915_sw_fence_await_sw_fence_gfp(>submit,
+>submit,
+I915_FENCE_GFP);


I guess we really should be respecting the potential error here.
We should do the await before the emit, and out_add on err < 0.


Yep, completely missed it can return error even though GFP_KERNEL should 
have been a clue enough.



+
+   /* Order all following requests to be after. */
+   i915_timeline_set_barrier(ce->ring->timeline, rq);
+
+   /*
+* Guarantee context image and the timeline remains pinned until the
+* modifying request is retired by setting the ce activity tracker.
+*
+* But we only need to take one pin on the account of it. Or in other
+* words transfer the pinned ce object to tracked active request.
+*/
+   if (!i915_gem_active_isset(>active))
+   __intel_context_pin(ce);
+   i915_gem_active_set(>active, rq);
+
+out_add:
+   i915_request_add(rq);
+out_put:
+   intel_runtime_pm_put(i915);
+
+   return ret;
+}
+
+static int
+i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
+ struct intel_engine_cs *engine,
+ struct intel_sseu sseu)
+{
+   struct intel_context *ce = to_intel_context(ctx, engine);
+   int ret;
+
+   GEM_BUG_ON(INTEL_GEN(ctx->i915) < 8);
+   GEM_BUG_ON(engine->id != RCS);
+
+   ret = mutex_lock_interruptible(>i915->drm.struct_mutex);
+   if (ret)
+   return ret;
+
+   /* Nothing to do if unmodified. */
+   if (!memcmp(>sseu, , sizeof(sseu)))
+   goto out;


/* If oa is active, it has already overridden the per-context setting */
if (oa->active)
goto set;


I don't like sprinkling knowledge of OA to more places than is 
unavoidable. As such I prefer to centralize it to gen8_make_rpcs. Only 
downside to not do it is an useless re-configuration request, but I 
don't think we should care to optimize for the OA enabled case. If 
anything it could make the overall system perform better when analysed 
than when not. :)


Regards,

Tvrtko


+
+   /*
+* If context is not idle we have to submit an ordered request to modify
+* its context image via the kernel context. Pristine and idle contexts
+* will be configured on pinning.
+*/
+   if (ce->pin_count)
+   ret = gen8_modify_rpcs_gpu(ce, engine, sseu);
+
+   if (!ret)


set:


+   ce->sseu = sseu;
+
+out:
+   mutex_unlock(>i915->drm.struct_mutex);
+
+   return ret;

___
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 v10 0/2] Add XYUV format support

2018-09-17 Thread Juha-Pekka Heikkila

On 17.09.2018 11:25, Lisovskiy, Stanislav wrote:

On Fri, 2018-09-14 at 20:05 +0300, Juha-Pekka Heikkilä wrote:


Lisovskiy, Stanislav kirjoitti 14.9.2018 klo 17.30:

On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote:

On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav
wrote:

On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote:

Introduced new XYUV scan-in format for framebuffer and
added support for it to i915(SkyLake+).

Stanislav Lisovskiy (2):
drm: Introduce new DRM_FORMAT_XYUV
drm/i915: Adding YUV444 packed format support for skl+

   drivers/gpu/drm/drm_fourcc.c |  1 +
   drivers/gpu/drm/i915/i915_reg.h  |  2 +-
   drivers/gpu/drm/i915/intel_display.c | 15 +++
   drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
   include/uapi/drm/drm_fourcc.h|  1 +
   5 files changed, 20 insertions(+), 1 deletion(-)



Ping. There is an IGT patch which got Reviewed-by Ville.
This one left in order to get XYUV support.


Did we figure out userspace for this?

Was the conflict solved with the other guy (forgot who it is)
trying to add the same format with a different name?


Currently for userspace we have VLC(checked with Juha-Pekka) and
also IGT test case.


Hei, no. VLC was *not* showing the mode correctly back then when we
tested. VLC kms plugin is able to initialize the mode and it's all
stable but VLC didn't have correct video converter to reach matching
xYUV output. You remember Stan we tried to increase the recursion
for
decoding in case it would help? VLC doesn't have codec which produce
correct output, one of those xxx -> YUV plug-ins in VLC should be
patched before VLC can be considered as userspace for this mode.


Ok, I remember we managed to make it work somehow and saw some picture,
so for some reason I thought it is working already. What is our plan
then? Should we try to improve VLC codecs/plugins or may be I should
then work with some other user space case?



For VLC there are codecs which know about xYUV format but they seem to 
use it for input, I figure nobody so far needed it for output. If want 
to use VLC as userspace demo one of those codecs need to be patched up 
for outputting xYUV. As they already support many other YUV formats I 
wouldn't expect needed change to be significant on code level as KMS 
support is already in VLC.




/Juha-Pekka



I think those guys were from ARM and they were adding also support
for
XYUV. The only difference was that they called XYUV, like XYUV
something.
Our patches were otherwise identical regarding drm_fourcc.c part, I
don't see their stuff merged, but I guess it really shouldn't
matter,
who does this first. i915 specific part doesn't conflict with their
stuff. To be honest, I forgot the guy's name neither could find his
email in my mailbox.
So hopefully somebody shows up here.





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


Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support

2018-09-17 Thread Alexandru-Cosmin Gheorghe
Hi,

On Mon, Sep 17, 2018 at 08:27:18AM +, Lisovskiy, Stanislav wrote:
> On Fri, 2018-09-14 at 14:59 +, Alexandru-Cosmin Gheorghe wrote:
> > On Fri, Sep 14, 2018 at 02:49:09PM +, Lisovskiy, Stanislav wrote:
> > > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote:
> > > > Hi, 
> > > > 
> > > > > -Original Message-
> > > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org
> > > > > ] On
> > > > > Behalf
> > > > > Of Lisovskiy, Stanislav
> > > > > Sent: perjantai 14. syyskuuta 2018 17.31
> > > > > To: ville.syrj...@linux.intel.com
> > > > > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> > > > >  > > > > intel.com>;
> > > > > Heikkila, Juha-pekka ; dri-
> > > > > de...@lists.freedesktop.org; Peres, Martin  > > > > com>
> > > > > Subject: Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format
> > > > > support
> > > > > 
> > > > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote:
> > > > > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy,
> > > > > > Stanislav
> > > > > > wrote:
> > > > > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy
> > > > > > > wrote:
> > > > > > > > Introduced new XYUV scan-in format for framebuffer and
> > > > > > > > added
> > > > > > > > support for it to i915(SkyLake+).
> > > > > > > > 
> > > > > > > > Stanislav Lisovskiy (2):
> > > > > > > >   drm: Introduce new DRM_FORMAT_XYUV
> > > > > > > >   drm/i915: Adding YUV444 packed format support for skl+
> > > > > > > > 
> > > > > > > >  drivers/gpu/drm/drm_fourcc.c |  1 +
> > > > > > > >  drivers/gpu/drm/i915/i915_reg.h  |  2 +-
> > > > > > > >  drivers/gpu/drm/i915/intel_display.c | 15
> > > > > > > > +++
> > > > > > > > drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
> > > > > > > >  include/uapi/drm/drm_fourcc.h|  1 +
> > > > > > > >  5 files changed, 20 insertions(+), 1 deletion(-)
> > > > > > > > 
> > > > > > > 
> > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville.
> > > > > > > This one left in order to get XYUV support.
> > > > > > 
> > > > > > Did we figure out userspace for this?
> > > > > > 
> > > > > > Was the conflict solved with the other guy (forgot who it is)
> > > > > > trying
> > > > > > to add the same format with a different name?
> > > > > 
> > > > > Currently for userspace we have VLC(checked with Juha-Pekka)
> > > > > and
> > > > > also IGT
> > > > > test case.
> > > > > 
> > > > > I think those guys were from ARM and they were adding also
> > > > > support
> > > > > for
> > > > > XYUV. The only difference was that they called XYUV, like
> > > > > XYUV
> > > > > something.
> > > > > Our patches were otherwise identical regarding drm_fourcc.c
> > > > > part, I
> > > > > don't
> > > > > see their stuff merged, but I guess it really shouldn't matter,
> > > > > who
> > > > > does this
> > > > > first. i915 specific part doesn't conflict with their stuff. To
> > > > > be
> > > > > honest, I forgot
> > > > > the guy's name neither could find his email in my mailbox.
> > > > > So hopefully somebody shows up here.
> > > > 
> > > > Stan:
> > > > Alexandru-Cosmin Gheorghe  ? 
> > > > 
> > > 
> > > Exactly, found now. Thanks for the hint! 
> > 
> > Yes, that's me.
> > Not a real conflict here, as long as your patches are ready to be
> > merged feel free to do it and I will just rebase my series on top of
> > that.
> 
> I can change DRM_FORMAT_XYUV naming to DRM_FORMAT_XYUV also, so
> that my patch series then is compatible with yours.

That would be nice.
Thank you.

> 
> > 
> > 
> > > 
> > > > > 
> > > > > > 
> > > > > 
> > > > > --
> > > > > Best Regards,
> > > > > 
> > > > > Lisovskiy Stanislav
> > > > > ___
> > > > > Intel-gfx mailing list
> > > > > Intel-gfx@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > 
> > > -- 
> > > Best Regards,
> > > 
> > > Lisovskiy Stanislav
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 
> -- 
> Best Regards,
> 
> Lisovskiy Stanislav

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


Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support

2018-09-17 Thread Lisovskiy, Stanislav
On Fri, 2018-09-14 at 14:59 +, Alexandru-Cosmin Gheorghe wrote:
> On Fri, Sep 14, 2018 at 02:49:09PM +, Lisovskiy, Stanislav wrote:
> > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote:
> > > Hi, 
> > > 
> > > > -Original Message-
> > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org
> > > > ] On
> > > > Behalf
> > > > Of Lisovskiy, Stanislav
> > > > Sent: perjantai 14. syyskuuta 2018 17.31
> > > > To: ville.syrj...@linux.intel.com
> > > > Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> > > >  > > > intel.com>;
> > > > Heikkila, Juha-pekka ; dri-
> > > > de...@lists.freedesktop.org; Peres, Martin  > > > com>
> > > > Subject: Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format
> > > > support
> > > > 
> > > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote:
> > > > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy,
> > > > > Stanislav
> > > > > wrote:
> > > > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy
> > > > > > wrote:
> > > > > > > Introduced new XYUV scan-in format for framebuffer and
> > > > > > > added
> > > > > > > support for it to i915(SkyLake+).
> > > > > > > 
> > > > > > > Stanislav Lisovskiy (2):
> > > > > > >   drm: Introduce new DRM_FORMAT_XYUV
> > > > > > >   drm/i915: Adding YUV444 packed format support for skl+
> > > > > > > 
> > > > > > >  drivers/gpu/drm/drm_fourcc.c |  1 +
> > > > > > >  drivers/gpu/drm/i915/i915_reg.h  |  2 +-
> > > > > > >  drivers/gpu/drm/i915/intel_display.c | 15
> > > > > > > +++
> > > > > > > drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
> > > > > > >  include/uapi/drm/drm_fourcc.h|  1 +
> > > > > > >  5 files changed, 20 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > 
> > > > > > Ping. There is an IGT patch which got Reviewed-by Ville.
> > > > > > This one left in order to get XYUV support.
> > > > > 
> > > > > Did we figure out userspace for this?
> > > > > 
> > > > > Was the conflict solved with the other guy (forgot who it is)
> > > > > trying
> > > > > to add the same format with a different name?
> > > > 
> > > > Currently for userspace we have VLC(checked with Juha-Pekka)
> > > > and
> > > > also IGT
> > > > test case.
> > > > 
> > > > I think those guys were from ARM and they were adding also
> > > > support
> > > > for
> > > > XYUV. The only difference was that they called XYUV, like
> > > > XYUV
> > > > something.
> > > > Our patches were otherwise identical regarding drm_fourcc.c
> > > > part, I
> > > > don't
> > > > see their stuff merged, but I guess it really shouldn't matter,
> > > > who
> > > > does this
> > > > first. i915 specific part doesn't conflict with their stuff. To
> > > > be
> > > > honest, I forgot
> > > > the guy's name neither could find his email in my mailbox.
> > > > So hopefully somebody shows up here.
> > > 
> > > Stan:
> > > Alexandru-Cosmin Gheorghe  ? 
> > > 
> > 
> > Exactly, found now. Thanks for the hint! 
> 
> Yes, that's me.
> Not a real conflict here, as long as your patches are ready to be
> merged feel free to do it and I will just rebase my series on top of
> that.

I can change DRM_FORMAT_XYUV naming to DRM_FORMAT_XYUV also, so
that my patch series then is compatible with yours.

> 
> 
> > 
> > > > 
> > > > > 
> > > > 
> > > > --
> > > > Best Regards,
> > > > 
> > > > Lisovskiy Stanislav
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Best Regards,
> > 
> > Lisovskiy Stanislav
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
-- 
Best Regards,

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


Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support

2018-09-17 Thread Lisovskiy, Stanislav
On Fri, 2018-09-14 at 20:05 +0300, Juha-Pekka Heikkilä wrote:
> 
> Lisovskiy, Stanislav kirjoitti 14.9.2018 klo 17.30:
> > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote:
> > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav
> > > wrote:
> > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote:
> > > > > Introduced new XYUV scan-in format for framebuffer and
> > > > > added support for it to i915(SkyLake+).
> > > > > 
> > > > > Stanislav Lisovskiy (2):
> > > > >drm: Introduce new DRM_FORMAT_XYUV
> > > > >drm/i915: Adding YUV444 packed format support for skl+
> > > > > 
> > > > >   drivers/gpu/drm/drm_fourcc.c |  1 +
> > > > >   drivers/gpu/drm/i915/i915_reg.h  |  2 +-
> > > > >   drivers/gpu/drm/i915/intel_display.c | 15 +++
> > > > >   drivers/gpu/drm/i915/intel_sprite.c  |  2 ++
> > > > >   include/uapi/drm/drm_fourcc.h|  1 +
> > > > >   5 files changed, 20 insertions(+), 1 deletion(-)
> > > > > 
> > > > 
> > > > Ping. There is an IGT patch which got Reviewed-by Ville.
> > > > This one left in order to get XYUV support.
> > > 
> > > Did we figure out userspace for this?
> > > 
> > > Was the conflict solved with the other guy (forgot who it is)
> > > trying to add the same format with a different name?
> > 
> > Currently for userspace we have VLC(checked with Juha-Pekka) and
> > also IGT test case.
> 
> Hei, no. VLC was *not* showing the mode correctly back then when we 
> tested. VLC kms plugin is able to initialize the mode and it's all 
> stable but VLC didn't have correct video converter to reach matching 
> xYUV output. You remember Stan we tried to increase the recursion
> for 
> decoding in case it would help? VLC doesn't have codec which produce 
> correct output, one of those xxx -> YUV plug-ins in VLC should be 
> patched before VLC can be considered as userspace for this mode.

Ok, I remember we managed to make it work somehow and saw some picture,
so for some reason I thought it is working already. What is our plan
then? Should we try to improve VLC codecs/plugins or may be I should
then work with some other user space case?

> 
> /Juha-Pekka
> 
> > 
> > I think those guys were from ARM and they were adding also support
> > for
> > XYUV. The only difference was that they called XYUV, like XYUV
> > something.
> > Our patches were otherwise identical regarding drm_fourcc.c part, I
> > don't see their stuff merged, but I guess it really shouldn't
> > matter,
> > who does this first. i915 specific part doesn't conflict with their
> > stuff. To be honest, I forgot the guy's name neither could find his
> > email in my mailbox.
> > So hopefully somebody shows up here.
> > 
> > > 
-- 
Best Regards,

Lisovskiy Stanislav
___
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/psr: Enable AUX-A IO power well on ICL for PSR (rev3)

2018-09-17 Thread Patchwork
== Series Details ==

Series: drm/i915/psr: Enable AUX-A IO power well on ICL for PSR (rev3)
URL   : https://patchwork.freedesktop.org/series/49682/
State : failure

== Summary ==

Applying: drm/i915/psr: Enable AUX-A IO power well on ICL for PSR
error: corrupt patch at line 27
error: could not build fake ancestor
Patch failed at 0001 drm/i915/psr: Enable AUX-A IO power well on ICL for PSR
Use 'git am --show-current-patch' to see the failed 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] drm/i915/psr: Enable AUX-A IO power well on ICL for PSR

2018-09-17 Thread Yadav, Jyoti R
Hi Dhinakaran,

I tested this patch. Now I am not able to see those "AUX  Error Interrupts".
Thanks for your patch.

Regards
Jyoti

-Original Message-
From: Pandiyan, Dhinakaran 
Sent: Friday, September 14, 2018 5:48 AM
To: intel-gfx@lists.freedesktop.org
Cc: Souza, Jose ; Deak, Imre ; 
Pandiyan, Dhinakaran ; Atwood, Matthew S 
; Yadav, Jyoti R ; Bowman, 
Casey G 
Subject: [PATCH] drm/i915/psr: Enable AUX-A IO power well on ICL for PSR

PSR requires AUX IO power well to be enabled. This was already in place for 
CNL, extend this for ICL too. Not enabling the power well results in the aux 
error interrupts when the hardware exits PSR.

Reported-by: Casey G Bowman 
Reported-by: Jyoti R Yadav 
Cc: Matt Atwood 
Cc: Jyoti R Yadav 
Cc: Casey G Bowman 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_ddi.c| 2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cd01a09c5e0f..b6910c8b4e08 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2077,7 +2077,7 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
*encoder,  static inline enum intel_display_power_domain  
intel_ddi_main_link_aux_domain(struct intel_dp *intel_dp)  {
-   /* CNL HW requires corresponding AUX IOs to be powered up for PSR with
+   /* CNL+ HW requires corresponding AUX IOs to be powered up for PSR 
+with
 * DC states enabled at the same time, while for driver initiated AUX
 * transfers we need the same AUX IOs to be powered but with DC states
 * disabled. Accordingly use the AUX power domain here which leaves DC 
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 9bebec389de1..0fdabce647ab 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1996,6 +1996,7 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
BIT_ULL(POWER_DOMAIN_PORT_DDI_F_IO))
 
 #define ICL_AUX_A_IO_POWER_DOMAINS (   \
+   BIT_ULL(POWER_DOMAIN_AUX_IO_A) |\
BIT_ULL(POWER_DOMAIN_AUX_A))
 #define ICL_AUX_B_IO_POWER_DOMAINS (   \
BIT_ULL(POWER_DOMAIN_AUX_B))
--
2.17.1

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