Re: [Intel-gfx] [PATCH 01/12] tests/kms_atomic_transition: use select + read instead of blocking read

[Daniel Vetter]

On Mon, Nov 14, 2016 at 06:59:14PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> If the event never arrives we can timeout with select and end the test.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  tests/kms_atomic_transition.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
> index 1977993..e693c88 100644
> --- a/tests/kms_atomic_transition.c
> +++ b/tests/kms_atomic_transition.c
> @@ -296,6 +296,14 @@ static void commit_display(igt_display_t *display, 
> unsigned event_mask, bool non
>   struct drm_event *e = (void *)buf;
>   struct drm_event_vblank *vblank = (void *)buf;
>   uint32_t crtc_id, pipe = I915_MAX_PIPES;
> + struct timeval timeout = { .tv_sec = 3, .tv_usec = 0 };
> + fd_set fds;
> +
> + FD_ZERO();
> + FD_SET(0, );
> + FD_SET(display->drm_fd, );
> + ret = select(display->drm_fd + 1, , NULL, NULL, );
> + igt_assert(ret > 0);

Hm, we have igt_timeout which sends a signal and kills the test if the
timeout expires. And drm event reading should be interruptible. That might
be an even simpler way to implement this.
-Daniel

>  
>   ret = read(display->drm_fd, buf, sizeof(buf));
>   if (ret < 0 && (errno == EINTR || errno == EAGAIN))
> -- 
> 2.5.5
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

[Daniel Vetter]

On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> In the usual working scenarios, this property is "Good".
> If something fails during modeset, the DRM driver can
> set the link status to "Bad", prune the mode list based on the
> link rate/lane count fallback values and send  hotplug uevent
> so that userspace that is aware of this property can take an
> appropriate action by reprobing connectors and re triggering
> a modeset to improve user experience and avoid black screens.
> In case of userspace that is not aware of this link status
> property, the user experience will be unchanged.
> 
> The reason for adding the property is to handle link training failures,
> but it is not limited to DP or link training. For example, if we
> implement asynchronous setcrtc, we can use this to report any failures
> in that.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 

One more thing I've forgotten: Just adding the kernel-doc isn't enough
yet, we need to link this new property into the overall property
documentations.

We already have a section "KMS Properties" in
Documentation/gpu/drm-kms.rst, I think adding a new sub-section called
"Standard Connector Properties" there with a definition list pointing to
this function here would be best.
-Daniel

> ---
>  drivers/gpu/drm/drm_connector.c | 38 ++
>  include/drm/drm_connector.h |  2 ++
>  2 files changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index d4e852f..09f4093 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
>  
> +/**
> + * drm_mode_connector_set_link_status_property - Set the link status 
> property of
> + * a connector to indicate status of link as a result of link training.
> + * @connector: drm connector
> + * @link_status: new value of link status property (0: Good, 1: Bad)
> + *
> + * In usual working scenario, this link status property will always be set to
> + * "GOOD".
> + * If something fails during or after a mode set, the kernel driver can set 
> this
> + * link status to "BAD", prune the mode list based on new information and 
> send a
> + * hotplug uevent for userspace to have it re-check the valid modes through
> + * Get_connector and try again.
> + *
> + * If userspace is not aware of this property, the user experience is the 
> same
> + * as it currently is. If the userspace is aware of the property, it has a 
> chance
> + * to improve user experience by handling link training failures, avoiding 
> black
> + * screens. The DRM driver can chose to not modify property and keep link 
> status
> + * as "GOOD" always to keep the user experience same as it currently is.
> + *
> + * The reason for adding this property is to handle link training failures, 
> but
> + * it is not limited to DP or link training. For example, if we implement
> + * asynchronous setcrtc, this property can be used to reportany failures in 
> that.
> + *
> + * This function must be called from asynchronous work item.
> + * Returns zero on success and negative errrno on failure.
> + */
> +int drm_mode_connector_set_link_status_property(struct drm_connector 
> *connector,
> + uint64_t link_status)
> +{
> + struct drm_device *dev = connector->dev;
> +
> + connector->link_status = link_status;
> + return drm_object_property_set_value(>base,
> +  
> dev->mode_config.link_status_property,
> +  link_status);
> +}
> +EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
> +
>  int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
>   struct drm_property *property,
>   uint64_t value)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ad5c8b0..ac76469 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct 
> drm_connector *connector,
>  int drm_mode_connector_set_tile_property(struct drm_connector *connector);
>  int drm_mode_connector_update_edid_property(struct drm_connector *connector,
>   const struct edid *edid);
> +int drm_mode_connector_set_link_status_property(struct drm_connector 
> *connector,
> + uint64_t link_status);
>  
>  /**
>   * drm_for_each_connector - iterate over all connectors
> -- 
> 1.9.1
> 
> 

Re: [Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

[Daniel Vetter]

On Mon, Nov 14, 2016 at 07:23:33PM -0800, Manasi Navare wrote:
> None of the other functions that set the connector property hold the 
> mode config locks while setting the connector property, I am following
> the same convention.
> Also we dont need to grab and release the locks in i915_modeset_work_func
> that first validates the modes and then sets this link status property.

Which other functions don't hold the mode_config.mutex?
-Daniel

> 
> Manasi
> 
> On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> > In the usual working scenarios, this property is "Good".
> > If something fails during modeset, the DRM driver can
> > set the link status to "Bad", prune the mode list based on the
> > link rate/lane count fallback values and send  hotplug uevent
> > so that userspace that is aware of this property can take an
> > appropriate action by reprobing connectors and re triggering
> > a modeset to improve user experience and avoid black screens.
> > In case of userspace that is not aware of this link status
> > property, the user experience will be unchanged.
> > 
> > The reason for adding the property is to handle link training failures,
> > but it is not limited to DP or link training. For example, if we
> > implement asynchronous setcrtc, we can use this to report any failures
> > in that.
> > 
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/drm_connector.c | 38 ++
> >  include/drm/drm_connector.h |  2 ++
> >  2 files changed, 40 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index d4e852f..09f4093 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct 
> > drm_connector *connector,
> >  }
> >  EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
> >  
> > +/**
> > + * drm_mode_connector_set_link_status_property - Set the link status 
> > property of
> > + * a connector to indicate status of link as a result of link training.
> > + * @connector: drm connector
> > + * @link_status: new value of link status property (0: Good, 1: Bad)
> > + *
> > + * In usual working scenario, this link status property will always be set 
> > to
> > + * "GOOD".
> > + * If something fails during or after a mode set, the kernel driver can 
> > set this
> > + * link status to "BAD", prune the mode list based on new information and 
> > send a
> > + * hotplug uevent for userspace to have it re-check the valid modes through
> > + * Get_connector and try again.
> > + *
> > + * If userspace is not aware of this property, the user experience is the 
> > same
> > + * as it currently is. If the userspace is aware of the property, it has a 
> > chance
> > + * to improve user experience by handling link training failures, avoiding 
> > black
> > + * screens. The DRM driver can chose to not modify property and keep link 
> > status
> > + * as "GOOD" always to keep the user experience same as it currently is.
> > + *
> > + * The reason for adding this property is to handle link training 
> > failures, but
> > + * it is not limited to DP or link training. For example, if we implement
> > + * asynchronous setcrtc, this property can be used to reportany failures 
> > in that.
> > + *
> > + * This function must be called from asynchronous work item.
> > + * Returns zero on success and negative errrno on failure.
> > + */
> > +int drm_mode_connector_set_link_status_property(struct drm_connector 
> > *connector,
> > +   uint64_t link_status)
> > +{
> > +   struct drm_device *dev = connector->dev;
> > +
> > +   connector->link_status = link_status;
> > +   return drm_object_property_set_value(>base,
> > +
> > dev->mode_config.link_status_property,
> > +link_status);
> > +}
> > +EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
> > +
> >  int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
> > struct drm_property *property,
> > uint64_t value)
> > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > index ad5c8b0..ac76469 100644
> > --- a/include/drm/drm_connector.h
> > +++ b/include/drm/drm_connector.h
> > @@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct 
> > drm_connector *connector,
> >  int drm_mode_connector_set_tile_property(struct drm_connector *connector);
> >  int drm_mode_connector_update_edid_property(struct drm_connector 
> > *connector,
> > const struct edid *edid);
> > +int 

Re: [Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

[Daniel Vetter]

On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> In the usual working scenarios, this property is "Good".
> If something fails during modeset, the DRM driver can
> set the link status to "Bad", prune the mode list based on the
> link rate/lane count fallback values and send  hotplug uevent
> so that userspace that is aware of this property can take an
> appropriate action by reprobing connectors and re triggering
> a modeset to improve user experience and avoid black screens.
> In case of userspace that is not aware of this link status
> property, the user experience will be unchanged.
> 
> The reason for adding the property is to handle link training failures,
> but it is not limited to DP or link training. For example, if we
> implement asynchronous setcrtc, we can use this to report any failures
> in that.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_connector.c | 38 ++
>  include/drm/drm_connector.h |  2 ++
>  2 files changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index d4e852f..09f4093 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
>  
> +/**
> + * drm_mode_connector_set_link_status_property - Set the link status 
> property of
> + * a connector to indicate status of link as a result of link training.

iirc this continuation upsets kernel-doc. Did you build the docs and
review them? You need to indent the 2nd line.

Also, might just shorten it to "set link status for a connector", details
are for the text below.

> + * @connector: drm connector
> + * @link_status: new value of link status property (0: Good, 1: Bad)
> + *
> + * In usual working scenario, this link status property will always be set to
> + * "GOOD".

Unecessary linebbreak. Either make a full paragraph (empty line) or
reflow, this here won't survivie kernel-doc formatting.

> + * If something fails during or after a mode set, the kernel driver can set 
> this
> + * link status to "BAD", prune the mode list based on new information and 
> send a

First need to prune the mode list, then set the property. Please reorder
in your text.

> + * hotplug uevent for userspace to have it re-check the valid modes through
> + * Get_connector and try again.

s/Get_connector/GET_CONNECTOR IOCTL/ is the more usual style.

> + *
> + * If userspace is not aware of this property, the user experience is the 
> same
> + * as it currently is. If the userspace is aware of the property, it has a 
> chance
> + * to improve user experience by handling link training failures, avoiding 
> black
> + * screens. The DRM driver can chose to not modify property and keep link 
> status
> + * as "GOOD" always to keep the user experience same as it currently is.

Imo this paragraph isn't needed. Maybe just mention that old userspace
exists:

"Note that a lot of existing userspace doesn't handle this property.
Drivers can therefore not rely on userspace to fix up everything and
should try to handle issues (like just re-training a link) without
userspace's intervention. This should only be used when the current mode
doesn't work any more, and userspace must select a different display
mode."

> + *
> + * The reason for adding this property is to handle link training failures, 
> but
> + * it is not limited to DP or link training. For example, if we implement
> + * asynchronous setcrtc, this property can be used to reportany failures in 
> that.

s/reportany/report/

> + *
> + * This function must be called from asynchronous work item.

This isn't true - it doesn't require an asynchronous work item, but the
locking rules mean that it.

> + * Returns zero on success and negative errrno on failure.

Hm, why can this ever fail? Intuitively this should never fail, and hence
we shouldn't need an error return value.

> + */
> +int drm_mode_connector_set_link_status_property(struct drm_connector 
> *connector,
> + uint64_t link_status)
> +{
> + struct drm_device *dev = connector->dev;
> +
> + connector->link_status = link_status;
> + return drm_object_property_set_value(>base,
> +  
> dev->mode_config.link_status_property,
> +  link_status);

This misses the hotplug_event call from my proposal.  Intentionally? Why?

Also: With the current code you require that mode_config.mutex is held by
the caller. Every time you add a library/core function which requires
certain locks to be held, please check that 

Re: [Intel-gfx] [PATCH v5 3/3] drm/i915/bxt: add bxt dsi gpio element support

[Mika Kahola]

Tested-by: Mika Kahola 

On Tue, 2016-04-26 at 13:27 +0300, Jani Nikula wrote:
> Request the GPIO by index through the consumer API. For now, use a
> quick
> hack to store the already requested ones, simply because I have no
> idea
> whether this actually works or not, and I have no way to test it.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 28
> +++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index f122484bedfc..aefcc19968e0 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -300,6 +301,31 @@ static void chv_exec_gpio(struct
> drm_i915_private *dev_priv,
>   mutex_unlock(_priv->sb_lock);
>  }
>  
> +static void bxt_exec_gpio(struct drm_i915_private *dev_priv,
> +   u8 gpio_source, u8 gpio_index, bool value)
> +{
> + /* XXX: this table is a quick ugly hack. */
> + static struct gpio_desc *bxt_gpio_table[U8_MAX + 1];
> + struct gpio_desc *gpio_desc = bxt_gpio_table[gpio_index];
> +
> + if (!gpio_desc) {
> + gpio_desc = devm_gpiod_get_index(dev_priv->dev->dev,
> +  NULL, gpio_index,
> +  value ?
> GPIOD_OUT_LOW :
> +  GPIOD_OUT_HIGH);
> +
> + if (IS_ERR_OR_NULL(gpio_desc)) {
> + DRM_ERROR("GPIO index %u request failed
> (%ld)\n",
> +   gpio_index, PTR_ERR(gpio_desc));
> + return;
> + }
> +
> + bxt_gpio_table[gpio_index] = gpio_desc;
> + }
> +
> + gpiod_set_value(gpio_desc, value);
> +}
> +
>  static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const
> u8 *data)
>  {
>   struct drm_device *dev = intel_dsi->base.base.dev;
> @@ -326,7 +352,7 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
> *intel_dsi, const u8 *data)
>   else if (IS_CHERRYVIEW(dev_priv))
>   chv_exec_gpio(dev_priv, gpio_source, gpio_index,
> value);
>   else
> - DRM_DEBUG_KMS("GPIO element not supported on this
> platform\n");
> + bxt_exec_gpio(dev_priv, gpio_source, gpio_index,
> value);
>  
>   return data;
>  }
-- 
Mika Kahola - Intel OTC

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/audio: extend get_saved_enc() to support more scenarios

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/audio: extend get_saved_enc() to 
support more scenarios
URL   : https://patchwork.freedesktop.org/series/15321/
State : success

== Summary ==

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


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

2f21978cfd8984c79e4cbd77ce63d9f73fe226ef drm-intel-nightly: 
2016y-11m-14d-21h-23m-10s UTC integration manifest
de72750 drm/i915/audio: Extend audio sync rate support for DP MST
06279ec drm/i915/audio: extend get_saved_enc() to support more scenarios

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2995/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

[Harry Wentland]

Overall this patch set makes sense but I think it would be good to move 
some stuff to common code instead of leaving it in i915. I'm thinking 
about patch 2 (setting the link status property) in particular but also 
tend to agree with Ville and Daniel about their comments for patch 5.


That said, should another driver need it it shouldn't be hard to pull 
that out.


Patch 1: Reviewed-by: Harry Wentland 

Patch 2-5: Acked-by: Harry Wentland 

Harry


On 2016-11-09 11:42 PM, Manasi Navare wrote:

Link training failure is handled by lowering the link rate first
until it reaches the minimum and keeping the lane count maximum
and then lowering the lane count until it reaches minimim. These
fallback values are saved and hotplug uevent is sent to the userspace
after setting the connector link status property to BAD. Userspace
should triiger another modeset on a uevent and if link status property
is BAD. This will retrain the link at fallback values.
This is repeated until the link is successfully trained.

This has been validated to pass DP compliance.

Manasi Navare (5):
   drm: Add a new connector property for link status
   drm/i915: Set link status property for DP connector
   drm/i915: Update CRTC state if connector link status property changed
   drm/i915: Find fallback link rate/lane count
   drm/i915: Implement Link Rate fallback on Link training failure

  drivers/gpu/drm/drm_atomic_helper.c   |   7 ++
  drivers/gpu/drm/drm_connector.c   |  17 
  drivers/gpu/drm/i915/intel_ddi.c  |  21 +++-
  drivers/gpu/drm/i915/intel_dp.c   | 138 +-
  drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
  drivers/gpu/drm/i915/intel_drv.h  |  12 ++-
  include/drm/drm_connector.h   |   7 +-
  include/drm/drm_crtc.h|   5 +
  include/uapi/drm/drm_mode.h   |   4 +
  9 files changed, 214 insertions(+), 9 deletions(-)



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

Re: [Intel-gfx] [PATCH] dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

[Daniel Vetter]

On Mon, Nov 14, 2016 at 04:37:09PM +0100, Christian König wrote:
> Am 14.11.2016 um 12:55 schrieb Chris Wilson:
> > The current code is subject to a race where we may try to acquire a
> > reference on a stale fence:
> > 
> > [13703.335118] WARNING: CPU: 1 PID: 14975 at ./include/linux/kref.h:46 
> > i915_gem_object_wait+0x1a3/0x1c0
> > [13703.335184] Modules linked in:
> > [13703.335202] CPU: 1 PID: 14975 Comm: gem_concurrent_ Not tainted 
> > 4.9.0-rc4+ #26
> > [13703.335216] Hardware name:  /, BIOS 
> > PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
> > [13703.335233]  c90002f5bcc8 812807de  
> > 
> > [13703.335257]  c90002f5bd08 81073811 002e8000 
> > 88026bf7c780
> > [13703.335279]  7fff 0001 88027045a550 
> > 88026bf7c780
> > [13703.335301] Call Trace:
> > [13703.335316]  [] dump_stack+0x4d/0x6f
> > [13703.335331]  [] __warn+0xc1/0xe0
> > [13703.335343]  [] warn_slowpath_null+0x18/0x20
> > [13703.335355]  [] i915_gem_object_wait+0x1a3/0x1c0
> > [13703.335367]  [] i915_gem_set_domain_ioctl+0xcc/0x330
> > [13703.335386]  [] drm_ioctl+0x1cb/0x410
> > [13703.335400]  [] ? 
> > i915_gem_obj_prepare_shmem_write+0x1d0/0x1d0
> > [13703.335416]  [] ? drm_ioctl+0x2bb/0x410
> > [13703.335429]  [] do_vfs_ioctl+0x8f/0x5c0
> > [13703.335442]  [] SyS_ioctl+0x3c/0x70
> > [13703.335456]  [] entry_SYSCALL_64_fastpath+0x17/0x98
> > [13703.335558] ---[ end trace fd24176416ba6981 ]---
> > [13703.382778] general protection fault:  [#1] SMP
> > [13703.382802] Modules linked in:
> > [13703.382816] CPU: 1 PID: 14967 Comm: gem_concurrent_ Tainted: GW  
> >  4.9.0-rc4+ #26
> > [13703.382828] Hardware name:  /, BIOS 
> > PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
> > [13703.382841] task: 880275458000 task.stack: c90002f18000
> > [13703.382849] RIP: 0010:[]  [] 
> > i915_gem_request_retire+0x2b4/0x320
> > [13703.382870] RSP: 0018:c90002f1bbc8  EFLAGS: 00010293
> > [13703.382878] RAX: dead0200 RBX: 88026bf7dce8 RCX: 
> > dead0100
> > [13703.382887] RDX: dead0100 RSI: 88026bf7c930 RDI: 
> > 88026bf7dd00
> > [13703.382897] RBP: c90002f1bbf8 R08:  R09: 
> > 88026b89a000
> > [13703.382905] R10: 0001 R11: 88026bbe8fe0 R12: 
> > 88026bf7c000
> > [13703.382913] R13: 880275af8000 R14: 88026bf7c180 R15: 
> > dead0200
> > [13703.382922] FS:  7f89e787d740() GS:88027fd0() 
> > knlGS:
> > [13703.382934] CS:  0010 DS:  ES:  CR0: 80050033
> > [13703.382942] CR2: 7f9053d2e000 CR3: 00026d414000 CR4: 
> > 001006e0
> > [13703.382951] Stack:
> > [13703.382958]  880275413000 c90002f1bde8 880275af8000 
> > 880274e8a600
> > [13703.382976]  880276a06000 c90002f1bde8 c90002f1bc38 
> > 813b48c5
> > [13703.382995]  c90002f1bc00 c90002f1bde8 88026972a440 
> > 
> > [13703.383021] Call Trace:
> > [13703.383032]  [] i915_gem_request_alloc+0xa5/0x350
> > [13703.383043]  [] 
> > i915_gem_do_execbuffer.isra.41+0x7b3/0x18b0
> > [13703.383055]  [] ? i915_gem_object_get_sg+0x25c/0x2b0
> > [13703.383065]  [] ? i915_gem_object_get_page+0x1d/0x50
> > [13703.383076]  [] ? i915_gem_pwrite_ioctl+0x66c/0x6d0
> > [13703.383086]  [] i915_gem_execbuffer2+0x95/0x1e0
> > [13703.383096]  [] drm_ioctl+0x1cb/0x410
> > [13703.383105]  [] ? i915_gem_execbuffer+0x2d0/0x2d0
> > [13703.383117]  [] ? hrtimer_start_range_ns+0x1a0/0x310
> > [13703.383128]  [] do_vfs_ioctl+0x8f/0x5c0
> > [13703.383140]  [] ? SyS_timer_settime+0x118/0x1a0
> > [13703.383150]  [] SyS_ioctl+0x3c/0x70
> > [13703.383162]  [] entry_SYSCALL_64_fastpath+0x17/0x98
> > [13703.383172] Code: 49 39 c6 48 8d 70 e8 48 8d 5f e8 75 16 eb 47 48 8d 43 
> > 18 48 8b 53 18 48 89 de 49 39 c6 48 8d 5a e8 74 33 48 8b 56 08 48 8b 46 10 
> > <48> 89 42 08 48 89 10 f6 46 38 01 48 89 4e 08 4c 89 7e 10 74 cf
> > [13703.383557] RIP  [] i915_gem_request_retire+0x2b4/0x320
> > [13703.383570]  RSP 
> > [13703.383586] ---[ end trace fd24176416ba6982 ]---
> > 
> > This is fixed by using the kref_get_unless_zero() as a full memory
> > barrier to validate the fence is still the current exclusive fence before
> > returning it back to the caller. (Note the fix only requires using
> > dma_fence_get_rcu() and correct handling, but we may as well use the
> > helper rather than inline equivalent code.)
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Sumit Semwal  
> Reviewed-by: Christian König .

Applied to drm-misc, thanks.
-Daniel

> 
> > ---
> >   include/linux/reservation.h | 15 ++-
> >   1 file changed, 6 insertions(+), 9 deletions(-)
> > 
> > diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> > index 2e313cca08f0..d9706a6f5ae2 100644
> > 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: Broxton decoupled MMIO (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/bxt: Broxton decoupled MMIO (rev4)
URL   : https://patchwork.freedesktop.org/series/12028/
State : success

== Summary ==

Series 12028v4 drm/i915/bxt: Broxton decoupled MMIO
https://patchwork.freedesktop.org/api/1.0/series/12028/revisions/4/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

2f21978cfd8984c79e4cbd77ce63d9f73fe226ef drm-intel-nightly: 
2016y-11m-14d-21h-23m-10s UTC integration manifest
f5effd2 drm/i915/bxt: Broxton decoupled MMIO

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2994/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v11 3/4] drm/i915: Use new CRC debugfs API

[David Weinehall]

On Mon, Nov 14, 2016 at 12:44:25PM +0200, Jani Nikula wrote:
> On Thu, 06 Oct 2016, Tomeu Vizoso  wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 23a6c7213eca..7412a05fa5d9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14636,6 +14636,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs 
> > = {
> > .page_flip = intel_crtc_page_flip,
> > .atomic_duplicate_state = intel_crtc_duplicate_state,
> > .atomic_destroy_state = intel_crtc_destroy_state,
> > +   .set_crc_source = intel_crtc_set_crc_source,
> >  };
> >  
> >  /**
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 737261b09110..31894b7c6517 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1844,6 +1844,14 @@ void intel_color_load_luts(struct drm_crtc_state 
> > *crtc_state);
> >  /* intel_pipe_crc.c */
> >  int intel_pipe_crc_create(struct drm_minor *minor);
> >  void intel_pipe_crc_cleanup(struct drm_minor *minor);
> > +#ifdef CONFIG_DEBUG_FS
> > +int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char 
> > *source_name,
> > + size_t *values_cnt);
> > +#else
> > +static inline int intel_crtc_set_crc_source(struct drm_crtc *crtc,
> > +   const char *source_name,
> > +   size_t *values_cnt) { return 0; }
> > +#endif
> 
> "inline" here doesn't work because it's used as a function pointer.
> 
> Is it better to have a function that returns 0 for .set_crc_source, or
> to set .set_crc_source to NULL when CONFIG_DEBUG_FS=n?

I'd say that whenever we have a function pointer we should have a dummy
function without side-effects for this kind of things.


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

[Intel-gfx] [PATCH 1/2] drm/i915/audio: extend get_saved_enc() to support more scenarios

[libin . yang]

From: Libin Yang 

When bootup, audio driver may not know it is MST or not. The audio
driver will poll all the port & pipe combinations in either MST or
Non-MST mode. get_saved_enc() should handle this situation.

Signed-off-by: Libin Yang 
---
 drivers/gpu/drm/i915/intel_audio.c | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index 49f1053..c8a1345 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -737,25 +737,49 @@ static int i915_audio_component_get_cdclk_freq(struct 
device *kdev)
return dev_priv->cdclk_freq;
 }
 
+/*
+ * get the intel_encoder according to the parameter port and pipe
+ * intel_encoder is saved by the index of pipe
+ * MST & (pipe >= 0): return the av_enc_map[pipe],
+ *   when port is matched
+ * MST & (pipe < 0): this is invalid
+ * Non-MST & (pipe >= 0): only pipe = 0 (the first device entry)
+ *   will get the right intel_encoder with port matched
+ * Non-MST & (pipe < 0): get the right intel_encoder with port matched
+ */
 static struct intel_encoder *get_saved_enc(struct drm_i915_private *dev_priv,
   int port, int pipe)
 {
+   struct intel_encoder *encoder;
 
if (WARN_ON(pipe >= I915_MAX_PIPES))
return NULL;
 
/* MST */
-   if (pipe >= 0)
-   return dev_priv->av_enc_map[pipe];
+   if (pipe >= 0) {
+   encoder = dev_priv->av_enc_map[pipe];
+   /*
+* when bootup, audio driver may not know it is
+* MST or not. So it will poll all the port & pipe
+* combinations
+*/
+   if (encoder != NULL && encoder->port == port &&
+   encoder->type == INTEL_OUTPUT_DP_MST)
+   return encoder;
+   }
 
/* Non-MST */
-   for_each_pipe(dev_priv, pipe) {
-   struct intel_encoder *encoder;
+   if (pipe > 0)
+   return NULL;
 
+   for_each_pipe(dev_priv, pipe) {
encoder = dev_priv->av_enc_map[pipe];
if (encoder == NULL)
continue;
 
+   if (encoder->type == INTEL_OUTPUT_DP_MST)
+   continue;
+
if (port == encoder->port)
return encoder;
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/2] drm/i915/audio: Extend audio sync rate support for DP MST

[libin . yang]

From: Libin Yang 

This patch extends the support of audio sample rate
sync up to DP MST.

Signed-off-by: Libin Yang 
---
 drivers/gpu/drm/i915/intel_audio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_audio.c 
b/drivers/gpu/drm/i915/intel_audio.c
index c8a1345..88ed869 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -807,7 +807,8 @@ static int i915_audio_component_sync_audio_rate(struct 
device *kdev, int port,
intel_encoder = get_saved_enc(dev_priv, port, pipe);
if (!intel_encoder || !intel_encoder->base.crtc ||
(intel_encoder->type != INTEL_OUTPUT_HDMI &&
-intel_encoder->type != INTEL_OUTPUT_DP)) {
+intel_encoder->type != INTEL_OUTPUT_DP &&
+intel_encoder->type != INTEL_OUTPUT_DP_MST)) {
DRM_DEBUG_KMS("Not valid for port %c\n", port_name(port));
err = -ENODEV;
goto unlock;
-- 
2.7.4

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass

[Saarinen, Jani]

> > == Series Details ==
> >
> > Series: series starting with [CI,01/10] drm/i915: Give each sw_fence its own
> lockclass
> > URL   : https://patchwork.freedesktop.org/series/15303/
> > State : warning
> >
> > == Summary ==
> >
> > Series 15303v1 Series without cover letter
> > https://patchwork.freedesktop.org/api/1.0/series/15303/revisions/1/mbo
> > x/
> >
> > Test drv_module_reload_basic:
> > pass   -> DMESG-WARN (fi-skl-6770hq)
> 
> That darn lpscon
>   [   36.848874] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
>   [   36.848916] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed 
> on port B

https://bugs.freedesktop.org/show_bug.cgi?id=98353. Imre has some progress on 
this.

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

[Intel-gfx] [PATCH v4] drm/i915/bxt: Broxton decoupled MMIO

[Praveen Paneri]

Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles for a single read/write and
avoids frequent software forcewake.
This certainly gives advantage over the forcewake as this new
mechanism “decouples” CPU cycles and allow them to complete even
when GT is in a CPD (frequency change) or C6 state.

This can co-exist with forcewake and we will continue to use forcewake
as appropriate. E.g. 64-bit register writes to avoid writing 2 dwords
separately and land into funny situations.

v2:
- Moved platform check out of the function and got rid of duplicate
 functions to find out decoupled power domain (Chris)
- Added a check for forcewake already held and skipped decoupled
 access (Chris)
- Skipped writing 64 bit registers through decoupled MMIO (Chris)

v3:
- Improved commit message with more info on decoupled mmio (Tvrtko)
- Changed decoupled operation to enum and used u32 instead of
 uint_32 data type for register offset (Tvrtko)
- Moved HAS_DECOUPLED_MMIO to device info (Tvrtko)
- Added lookup table for converting fw_engine to pd_engine (Tvrtko)
- Improved __gen9_decoupled_read and __gen9_decoupled_write
 routines (Tvrtko)

v4:
- Fixed alignment and variable names (Chris)
- Write GEN9_DECOUPLED_REG0_DW1 register in just one go (Zhe Wang)

Signed-off-by: Zhe Wang 
Signed-off-by: Praveen Paneri 
---
 drivers/gpu/drm/i915/i915_drv.h |  18 +-
 drivers/gpu/drm/i915/i915_pci.c |   1 +
 drivers/gpu/drm/i915/i915_reg.h |   7 +++
 drivers/gpu/drm/i915/intel_uncore.c | 109 
 4 files changed, 134 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4e7148a..158f05c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -549,6 +549,18 @@ enum forcewake_domains {
 #define FW_REG_READ  (1)
 #define FW_REG_WRITE (2)
 
+enum decoupled_power_domain {
+   GEN9_DECOUPLED_PD_BLITTER = 0,
+   GEN9_DECOUPLED_PD_RENDER,
+   GEN9_DECOUPLED_PD_MEDIA,
+   GEN9_DECOUPLED_PD_ALL
+};
+
+enum decoupled_ops {
+   GEN9_DECOUPLED_OP_WRITE = 0,
+   GEN9_DECOUPLED_OP_READ
+};
+
 enum forcewake_domains
 intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv,
   i915_reg_t reg, unsigned int op);
@@ -683,7 +695,8 @@ struct intel_csr {
func(cursor_needs_physical); \
func(hws_needs_physical); \
func(overlay_needs_physical); \
-   func(supports_tv)
+   func(supports_tv); \
+   func(has_decoupled_mmio)
 
 struct sseu_dev_info {
u8 slice_mask;
@@ -2652,6 +2665,9 @@ struct drm_i915_cmd_table {
 #define GT_FREQUENCY_MULTIPLIER 50
 #define GEN9_FREQ_SCALER 3
 
+#define HAS_DECOUPLED_MMIO(dev) (INTEL_INFO(dev)->has_decoupled_mmio \
+   && IS_BXT_REVID(dev, BXT_REVID_C0, REVID_FOREVER))
+
 #include "i915_trace.h"
 
 static inline bool intel_scanout_needs_vtd_wa(struct drm_i915_private 
*dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 70a99ce..fce8e19 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -363,6 +363,7 @@
.has_hw_contexts = 1,
.has_logical_ring_contexts = 1,
.has_guc = 1,
+   .has_decoupled_mmio = 1,
.ddb_size = 512,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3361d7f..c70c07a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7342,6 +7342,13 @@ enum {
 #define  SKL_FUSE_PG1_DIST_STATUS  (1<<26)
 #define  SKL_FUSE_PG2_DIST_STATUS  (1<<25)
 
+/* Decoupled MMIO register pair for kernel driver */
+#define GEN9_DECOUPLED_REG0_DW0_MMIO(0xF00)
+#define GEN9_DECOUPLED_REG0_DW1_MMIO(0xF04)
+#define GEN9_DECOUPLED_DW1_GO  (1<<31)
+#define GEN9_DECOUPLED_PD_SHIFT28
+#define GEN9_DECOUPLED_OP_SHIFT24
+
 /* Per-pipe DDI Function Control */
 #define _TRANS_DDI_FUNC_CTL_A  0x60400
 #define _TRANS_DDI_FUNC_CTL_B  0x61400
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index e2b188d..e4c50cb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -831,6 +831,66 @@ static bool is_gen8_shadowed(u32 offset)
__unclaimed_reg_debug(dev_priv, reg, read, before);
 }
 
+static const enum decoupled_power_domain fw2dpd_domain[] = {
+   GEN9_DECOUPLED_PD_RENDER,
+   GEN9_DECOUPLED_PD_BLITTER,
+   GEN9_DECOUPLED_PD_ALL,
+   GEN9_DECOUPLED_PD_MEDIA,
+   GEN9_DECOUPLED_PD_ALL,
+   GEN9_DECOUPLED_PD_ALL,
+   GEN9_DECOUPLED_PD_ALL
+};
+
+/*
+ * Decoupled MMIO access for only 1 DWORD
+ */
+static void 

Re: [Intel-gfx] [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math

[kbuild test robot]

Hi Dhinakaran,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.9-rc5 next-20161114]
[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/Dhinakaran-Pandiyan/drm-dp-i915-Fix-DP-link-rate-math/20161115-055743
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from include/linux/cache.h:4:0,
from include/linux/printk.h:8,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/i2c.h:30,
from drivers/gpu/drm/i915/intel_dp.c:28:
   drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_link_required':
>> drivers/gpu/drm/i915/intel_dp.c:168:22: error: 'pixel_clk' undeclared (first 
>> use in this function)
 return DIV_ROUND_UP(pixel_clk * bpp, 8);
 ^
   include/uapi/linux/kernel.h:12:40: note: in definition of macro 
'__KERNEL_DIV_ROUND_UP'
#define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
   ^
   drivers/gpu/drm/i915/intel_dp.c:168:9: note: in expansion of macro 
'DIV_ROUND_UP'
 return DIV_ROUND_UP(pixel_clk * bpp, 8);
^~~~
   drivers/gpu/drm/i915/intel_dp.c:168:22: note: each undeclared identifier is 
reported only once for each function it appears in
 return DIV_ROUND_UP(pixel_clk * bpp, 8);
 ^
   include/uapi/linux/kernel.h:12:40: note: in definition of macro 
'__KERNEL_DIV_ROUND_UP'
#define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
   ^
   drivers/gpu/drm/i915/intel_dp.c:168:9: note: in expansion of macro 
'DIV_ROUND_UP'
 return DIV_ROUND_UP(pixel_clk * bpp, 8);
^~~~
   drivers/gpu/drm/i915/intel_dp.c:169:1: warning: control reaches end of 
non-void function [-Wreturn-type]
}
^

vim +/pixel_clk +168 drivers/gpu/drm/i915/intel_dp.c

22   *
23   * Authors:
24   *Keith Packard <kei...@keithp.com>
25   *
26   */
27  
  > 28  #include 
29  #include 
30  #include 
31  #include 
32  #include 
33  #include 
34  #include 
35  #include 
36  #include 
37  #include 
38  #include "intel_drv.h"
39  #include 
40  #include "i915_drv.h"
41  
42  #define DP_LINK_CHECK_TIMEOUT   (10 * 1000)
43  
44  /* Compliance test status bits  */
45  #define INTEL_DP_RESOLUTION_SHIFT_MASK  0
46  #define INTEL_DP_RESOLUTION_PREFERRED   (1 << 
INTEL_DP_RESOLUTION_SHIFT_MASK)
47  #define INTEL_DP_RESOLUTION_STANDARD(2 << 
INTEL_DP_RESOLUTION_SHIFT_MASK)
48  #define INTEL_DP_RESOLUTION_FAILSAFE(3 << 
INTEL_DP_RESOLUTION_SHIFT_MASK)
49  
50  struct dp_link_dpll {
51  int clock;
52  struct dpll dpll;
53  };
54  
55  static const struct dp_link_dpll gen4_dpll[] = {
56  { 162000,
57  { .p1 = 2, .p2 = 10, .n = 2, .m1 = 23, .m2 = 8 } },
58  { 27,
59  { .p1 = 1, .p2 = 10, .n = 1, .m1 = 14, .m2 = 2 } }
60  };
61  
62  static const struct dp_link_dpll pch_dpll[] = {
63  { 162000,
64  { .p1 = 2, .p2 = 10, .n = 1, .m1 = 12, .m2 = 9 } },
65  { 27,
66  { .p1 = 1, .p2 = 10, .n = 2, .m1 = 14, .m2 = 8 } }
67  };
68  
69  static const struct dp_link_dpll vlv_dpll[] = {
70  { 162000,
71  { .p1 = 3, .p2 = 2, .n = 5, .m1 = 3, .m2 = 81 } },
72  { 27,
73  { .p1 = 2, .p2 = 2, .n = 1, .m1 = 2, .m2 = 27 } }
74  };
75  
76  /*
77   * CHV supports eDP 1.4 that have  more link rates.
78   * Below only provides the fixed rate but exclude variable rate.
79   */
80  static const struct dp_link_dpll chv_dpll[] = {
81  /*
82   * CHV requires to program fractional division for m2.
83   * m2 is stored in fixed point format using formula below
84   * (m2_int << 22) | m2_fraction
85   */
86  { 162000,   /* m2_int = 32, m2_fraction = 1677722 */
87  { .p1 = 4, .p2 = 2, .n = 1, .m1 = 2, .m2 = 0x81a } 
},
88  { 27,   /* m2_int = 27, m2_fraction = 0 */
89  { .p1 = 4, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } 
},
90  { 54,   /*

[Intel-gfx] ✓ Fi.CI.BAT: success for Handle Link Training Failure during modeset (rev2)

[Patchwork]

== Series Details ==

Series: Handle Link Training Failure during modeset (rev2)
URL   : https://patchwork.freedesktop.org/series/15080/
State : success

== Summary ==

Series 15080v2 Handle Link Training Failure during modeset
https://patchwork.freedesktop.org/api/1.0/series/15080/revisions/2/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

2f21978cfd8984c79e4cbd77ce63d9f73fe226ef drm-intel-nightly: 
2016y-11m-14d-21h-23m-10s UTC integration manifest
91a9d22 drm/i915: Implement Link Rate fallback on Link training failure
0b79f50 drm/i915: Find fallback link rate/lane count
f5c4dd7 drm/i915: Update CRTC state if connector link status property changed
79fe862 drm: Set DRM connector link status property
2f286cb drm: Add a new connector property for link status

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2993/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

[Manasi Navare]

None of the other functions that set the connector property hold the 
mode config locks while setting the connector property, I am following
the same convention.
Also we dont need to grab and release the locks in i915_modeset_work_func
that first validates the modes and then sets this link status property.

Manasi

On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> In the usual working scenarios, this property is "Good".
> If something fails during modeset, the DRM driver can
> set the link status to "Bad", prune the mode list based on the
> link rate/lane count fallback values and send  hotplug uevent
> so that userspace that is aware of this property can take an
> appropriate action by reprobing connectors and re triggering
> a modeset to improve user experience and avoid black screens.
> In case of userspace that is not aware of this link status
> property, the user experience will be unchanged.
> 
> The reason for adding the property is to handle link training failures,
> but it is not limited to DP or link training. For example, if we
> implement asynchronous setcrtc, we can use this to report any failures
> in that.
> 
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_connector.c | 38 ++
>  include/drm/drm_connector.h |  2 ++
>  2 files changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index d4e852f..09f4093 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
>  
> +/**
> + * drm_mode_connector_set_link_status_property - Set the link status 
> property of
> + * a connector to indicate status of link as a result of link training.
> + * @connector: drm connector
> + * @link_status: new value of link status property (0: Good, 1: Bad)
> + *
> + * In usual working scenario, this link status property will always be set to
> + * "GOOD".
> + * If something fails during or after a mode set, the kernel driver can set 
> this
> + * link status to "BAD", prune the mode list based on new information and 
> send a
> + * hotplug uevent for userspace to have it re-check the valid modes through
> + * Get_connector and try again.
> + *
> + * If userspace is not aware of this property, the user experience is the 
> same
> + * as it currently is. If the userspace is aware of the property, it has a 
> chance
> + * to improve user experience by handling link training failures, avoiding 
> black
> + * screens. The DRM driver can chose to not modify property and keep link 
> status
> + * as "GOOD" always to keep the user experience same as it currently is.
> + *
> + * The reason for adding this property is to handle link training failures, 
> but
> + * it is not limited to DP or link training. For example, if we implement
> + * asynchronous setcrtc, this property can be used to reportany failures in 
> that.
> + *
> + * This function must be called from asynchronous work item.
> + * Returns zero on success and negative errrno on failure.
> + */
> +int drm_mode_connector_set_link_status_property(struct drm_connector 
> *connector,
> + uint64_t link_status)
> +{
> + struct drm_device *dev = connector->dev;
> +
> + connector->link_status = link_status;
> + return drm_object_property_set_value(>base,
> +  
> dev->mode_config.link_status_property,
> +  link_status);
> +}
> +EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
> +
>  int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
>   struct drm_property *property,
>   uint64_t value)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ad5c8b0..ac76469 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct 
> drm_connector *connector,
>  int drm_mode_connector_set_tile_property(struct drm_connector *connector);
>  int drm_mode_connector_update_edid_property(struct drm_connector *connector,
>   const struct edid *edid);
> +int drm_mode_connector_set_link_status_property(struct drm_connector 
> *connector,
> + uint64_t link_status);
>  
>  /**
>   * drm_for_each_connector - iterate over all connectors
> -- 
> 1.9.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes. It will redo
the modeset on the current mode at lower link rate or if the current
mode gets pruned due to lower link constraints then, it will send a
hotplug uevent for userspace to handle it.

This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.

v5:
* Move set link status to drm core (Daniel Vetter, Jani Nikula)
v4:
* Add fallback support for non DDI platforms too
* Set connector->link status inside set_link_status function
(Jani Nikula)
v3:
* Set link status property to BAd unconditionally (Jani Nikula)
* Dont use two separate variables link_train_failed and link_status
to indicate same thing (Jani Nikula)
v2:
* Squashed a few patches (Jani Nikula)

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c  |  21 +-
 drivers/gpu/drm/i915/intel_dp.c   | 102 +-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
 drivers/gpu/drm/i915/intel_drv.h  |   6 +-
 4 files changed, 131 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0ad4e16..57b7ee9 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
 
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
@@ -1694,7 +1696,24 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder);
intel_ddi_init_dp_buf_reg(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-   intel_dp_start_link_train(intel_dp);
+   if (!intel_dp_start_link_train(intel_dp)) {
+   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane 
count = %d",
+ link_rate, lane_count);
+   if (!intel_dp_get_link_train_fallback_values(intel_dp,
+link_rate,
+lane_count))
+   /* Schedule a Hotplug Uevent to userspace to start 
modeset */
+   schedule_work(_connector->modeset_retry_work);
+   } else {
+   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane 
count = %d",
+ link_rate, lane_count);
+   intel_dp->fallback_link_rate_index = -1;
+   intel_dp->fallback_link_rate = 0;
+   intel_dp->fallback_lane_count = 0;
+   drm_mode_connector_set_link_status_property(connector,
+   
DRM_MODE_LINK_STATUS_GOOD);
+   }
+
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e87b451..af2f8b2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -353,8 +353,14 @@ int intel_dp_get_link_train_fallback_values(struct 
intel_dp *intel_dp,
target_clock = fixed_mode->clock;
}
 
-   max_link_clock = intel_dp_max_link_rate(intel_dp);
-   max_lanes = intel_dp_max_lane_count(intel_dp);
+   /* Prune the modes using the fallback link rate/lane count */
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
+   max_link_clock = intel_dp->fallback_link_rate;
+   max_lanes = intel_dp->fallback_lane_count;
+   } else {
+   max_link_clock = intel_dp_max_link_rate(intel_dp);
+   max_lanes = intel_dp_max_lane_count(intel_dp);
+   }
 
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
@@ -1591,6 +1597,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct 

[Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.

v2:
Squash the patch that returns the link rate index (Jani Nikula)

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 
Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c  | 42 
 drivers/gpu/drm/i915/intel_drv.h |  6 ++
 2 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a1b0181..e87b451 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,48 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
   common_rates);
 }
 
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+   int *common_rates, int link_rate)
+{
+   int common_len;
+   int index;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   for (index = 0; index < common_len; index++) {
+   if (link_rate == common_rates[common_len - index - 1])
+   return common_len - index - 1;
+   }
+
+   return -1;
+}
+
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+   int link_rate, uint8_t lane_count)
+{
+   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+   int common_len;
+   int link_rate_index = -1;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   link_rate_index = intel_dp_link_rate_index(intel_dp,
+  common_rates,
+  link_rate);
+   if (link_rate_index > 0) {
+   intel_dp->fallback_link_rate_index = link_rate_index - 1;
+   intel_dp->fallback_link_rate = 
common_rates[intel_dp->fallback_link_rate_index];
+   intel_dp->fallback_lane_count = 
intel_dp_max_lane_count(intel_dp);
+   } else if (lane_count > 1) {
+   intel_dp->fallback_link_rate_index = common_len - 1;
+   intel_dp->fallback_link_rate = 
common_rates[intel_dp->fallback_link_rate_index];
+   intel_dp->fallback_lane_count = lane_count >> 1;
+   } else {
+   DRM_ERROR("Link Training Unsuccessful\n");
+   return -1;
+   }
+
+   return 0;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 75252ec..55ceb44 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -887,6 +887,10 @@ struct intel_dp {
uint32_t DP;
int link_rate;
uint8_t lane_count;
+   int fallback_link_rate;
+   uint8_t fallback_lane_count;
+   int fallback_link_rate_index;
+   bool link_train_failed;
uint8_t sink_count;
bool link_mst;
bool has_audio;
@@ -1383,6 +1387,8 @@ bool intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
  int link_rate, uint8_t lane_count,
  bool link_mst);
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+   int link_rate, uint8_t lane_count);
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
-- 
1.9.1

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

[Intel-gfx] [PATCH 0/5] Handle link training failure during modeset

[Manasi Navare]

Submitting new series that adds proper commit messages/cover letter
and kernel documentation. It also moved the set_link_status function
to drm core so other kernel drivers can make use of it.

The idea presented in these patches is to address link training failure
in a way that:
a) changes the current happy day scenario as little as possible, to avoid
regressions, b) can be implemented the same way by all drm drivers, c)
is still opt-in for the drivers and userspace, and opting out doesn't
regress the user experience, d) doesn't prevent drivers from
implementing better or alternate approaches, possibly without userspace
involvement. And, of course, handles all the issues presented.

The solution is to add a "link status" connector property. In the usual
happy day scenario, this is always "good". If something fails during or
after a mode set, the kernel driver can set the link status to "bad",
prune the mode list based on new information as necessary, and send a
hotplug uevent for userspace to have it re-check the valid modes through
getconnector, and try again. If the theoretical capabilities of the link
can't be reached, the mode list is trimmed based on that.

If the userspace is not aware of the property, the user experience is
the same as it currently is. If the userspace is aware of the property,
it has a chance to improve user experience. If a drm driver does not
modify the property (it stays "good"), the user experience is the same
as it currently is. A drm driver can also choose to try to handle more
of the failures in kernel, hardware not limiting, or it can choose to
involve userspace more. Up to the drivers.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

Finally, while DP CTS compliance is advertized (which is great, and
could be made to work similarly for all drm drivers), this can be used
for the more important goal of improving user experience on link
training failures, by avoiding black screens.

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 

Manasi Navare (5):
  drm: Add a new connector property for link status
  drm: Set DRM connector link status property
  drm/i915: Update CRTC state if connector link status property changed
  drm/i915: Find fallback link rate/lane count
  drm/i915: Implement Link Rate fallback on Link training failure

 drivers/gpu/drm/drm_atomic_helper.c   |   7 ++
 drivers/gpu/drm/drm_connector.c   |  55 ++
 drivers/gpu/drm/i915/intel_ddi.c  |  21 +++-
 drivers/gpu/drm/i915/intel_dp.c   | 144 +-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
 drivers/gpu/drm/i915/intel_drv.h  |  10 +-
 include/drm/drm_connector.h   |   9 +-
 include/drm/drm_crtc.h|   5 +
 include/uapi/drm/drm_mode.h   |   4 +
 9 files changed, 257 insertions(+), 10 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 1/5] drm: Add a new connector property for link status

[Manasi Navare]

A new default connector property is added for keeping
track of whether the link is good (link training passed) or
link is bad (link training  failed). If the link status property
is not good, then userspace should fire off a new modeset at the current
mode even if there have not been any changes in the mode list
or connector status.
Also add link status connector member corersponding to the
decoded value of link status property.

v3:
* Drop "link training" from description since this is
not specific to DP (Jani Nikula)
* Add link status member to store property value locally
(Ville Syrjala)
v2:
* Make this a default connector property (Daniel Vetter)

Reviewed-by: Harry Wentland 
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 17 +
 include/drm/drm_connector.h |  7 ++-
 include/drm/drm_crtc.h  |  5 +
 include/uapi/drm/drm_mode.h |  4 
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2db7fb5..d4e852f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(>base,
  config->dpms_property, 0);
 
+   drm_object_attach_property(>base,
+  config->link_status_property,
+  0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
subpixel_order order)
 };
 DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
 
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -622,6 +632,13 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.tile_property = prop;
 
+   prop = drm_property_create_enum(dev, 0, "link-status",
+   drm_link_status_enum_list,
+   ARRAY_SIZE(drm_link_status_enum_list));
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.link_status_property = prop;
+
return 0;
 }
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3e97272..ad5c8b0 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -695,6 +695,12 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+   /* Connector Link status
+* 0: If the link is Good
+* 1: If the link is Bad
+*/
+   int link_status;
 };
 
 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
@@ -767,7 +773,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
-
 int drm_mode_connector_set_path_property(struct drm_connector *connector,
 const char *path);
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8cca2a8..a93148b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1164,6 +1164,11 @@ struct drm_mode_config {
 */
struct drm_property *tile_property;
/**
+* @link_status_property: Default connector property for link status
+* of a connector
+*/
+   struct drm_property *link_status_property;
+   /**
 * @plane_type_property: Default plane property to differentiate
 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 */
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 01000c9..66b145b 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -129,6 +129,10 @@
 #define DRM_MODE_DIRTY_ON   1
 #define DRM_MODE_DIRTY_ANNOTATE 2
 
+/* Link Status options */
+#define DRM_MODE_LINK_STATUS_GOOD  0
+#define DRM_MODE_LINK_STATUS_BAD   1
+
 struct drm_mode_modeinfo {
__u32 clock;
__u16 

[Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

[Manasi Navare]

In the usual working scenarios, this property is "Good".
If something fails during modeset, the DRM driver can
set the link status to "Bad", prune the mode list based on the
link rate/lane count fallback values and send  hotplug uevent
so that userspace that is aware of this property can take an
appropriate action by reprobing connectors and re triggering
a modeset to improve user experience and avoid black screens.
In case of userspace that is not aware of this link status
property, the user experience will be unchanged.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 38 ++
 include/drm/drm_connector.h |  2 ++
 2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d4e852f..09f4093 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
 
+/**
+ * drm_mode_connector_set_link_status_property - Set the link status property 
of
+ * a connector to indicate status of link as a result of link training.
+ * @connector: drm connector
+ * @link_status: new value of link status property (0: Good, 1: Bad)
+ *
+ * In usual working scenario, this link status property will always be set to
+ * "GOOD".
+ * If something fails during or after a mode set, the kernel driver can set 
this
+ * link status to "BAD", prune the mode list based on new information and send 
a
+ * hotplug uevent for userspace to have it re-check the valid modes through
+ * Get_connector and try again.
+ *
+ * If userspace is not aware of this property, the user experience is the same
+ * as it currently is. If the userspace is aware of the property, it has a 
chance
+ * to improve user experience by handling link training failures, avoiding 
black
+ * screens. The DRM driver can chose to not modify property and keep link 
status
+ * as "GOOD" always to keep the user experience same as it currently is.
+ *
+ * The reason for adding this property is to handle link training failures, but
+ * it is not limited to DP or link training. For example, if we implement
+ * asynchronous setcrtc, this property can be used to reportany failures in 
that.
+ *
+ * This function must be called from asynchronous work item.
+ * Returns zero on success and negative errrno on failure.
+ */
+int drm_mode_connector_set_link_status_property(struct drm_connector 
*connector,
+   uint64_t link_status)
+{
+   struct drm_device *dev = connector->dev;
+
+   connector->link_status = link_status;
+   return drm_object_property_set_value(>base,
+
dev->mode_config.link_status_property,
+link_status);
+}
+EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
+
 int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ad5c8b0..ac76469 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
 int drm_mode_connector_update_edid_property(struct drm_connector *connector,
const struct edid *edid);
+int drm_mode_connector_set_link_status_property(struct drm_connector 
*connector,
+   uint64_t link_status);
 
 /**
  * drm_for_each_connector - iterate over all connectors
-- 
1.9.1

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

[Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

CRTC state connector_changed needs to be set to true
if connector link status property has changed. This will tell the
driver to do a complete modeset due to change in connector property.

Acked-by: Harry Wentland 
Acked-by: Tony Cheng 
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_atomic_helper.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 5007796..aeecf2f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
   connector_state);
if (ret)
return ret;
+
+   if (connector->state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
connector->state->crtc);
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+   crtc_state->connectors_changed = true;
+   }
}
 
/*
-- 
1.9.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for HuC Loading Patches (rev2)

[Patchwork]

== Series Details ==

Series: HuC Loading Patches (rev2)
URL   : https://patchwork.freedesktop.org/series/15135/
State : success

== Summary ==

Series 15135v2 HuC Loading Patches
https://patchwork.freedesktop.org/api/1.0/series/15135/revisions/2/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

2f21978cfd8984c79e4cbd77ce63d9f73fe226ef drm-intel-nightly: 
2016y-11m-14d-21h-23m-10s UTC integration manifest
b927670 drm/i915/get_params: Add HuC status to getparams
38745f2 drm/i915/huc: Support HuC authentication
82f6f4c drm/i915/huc: Add debugfs for HuC loading status check
f1e42c3 drm/i915/HuC: Add KBL huC loading Support
8fdbd07 drm/i915/huc: Add BXT HuC Loading Support
11e8e88 drm/i915/huc: Add HuC fw loading support
8dc2f0d drm/i915/huc: Unified css_header struct for GuC and HuC
1a348ec drm/i915/guc: Make the GuC fw loading helper functions general

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2992/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

[Manasi Navare]

On Mon, Nov 14, 2016 at 08:07:39PM -0500, Harry Wentland wrote:
> Overall this patch set makes sense but I think it would be good to
> move some stuff to common code instead of leaving it in i915. I'm
> thinking about patch 2 (setting the link status property) in
> particular but also tend to agree with Ville and Daniel about their
> comments for patch 5.
> 
> That said, should another driver need it it shouldn't be hard to
> pull that out.
> 
> Patch 1: Reviewed-by: Harry Wentland 
> 
> Patch 2-5: Acked-by: Harry Wentland 
> 
> Harry
> 
>

Thanks for the review.
I am already moving Patch 2 set_link_status to the drm core as
per Daniel and Ville's suggestion. I will make those changes
and submit the new patches by EOD today.

Regards
Manasi
 
> On 2016-11-09 11:42 PM, Manasi Navare wrote:
> >Link training failure is handled by lowering the link rate first
> >until it reaches the minimum and keeping the lane count maximum
> >and then lowering the lane count until it reaches minimim. These
> >fallback values are saved and hotplug uevent is sent to the userspace
> >after setting the connector link status property to BAD. Userspace
> >should triiger another modeset on a uevent and if link status property
> >is BAD. This will retrain the link at fallback values.
> >This is repeated until the link is successfully trained.
> >
> >This has been validated to pass DP compliance.
> >
> >Manasi Navare (5):
> >   drm: Add a new connector property for link status
> >   drm/i915: Set link status property for DP connector
> >   drm/i915: Update CRTC state if connector link status property changed
> >   drm/i915: Find fallback link rate/lane count
> >   drm/i915: Implement Link Rate fallback on Link training failure
> >
> >  drivers/gpu/drm/drm_atomic_helper.c   |   7 ++
> >  drivers/gpu/drm/drm_connector.c   |  17 
> >  drivers/gpu/drm/i915/intel_ddi.c  |  21 +++-
> >  drivers/gpu/drm/i915/intel_dp.c   | 138 
> > +-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  |  12 ++-
> >  include/drm/drm_connector.h   |   7 +-
> >  include/drm/drm_crtc.h|   5 +
> >  include/uapi/drm/drm_mode.h   |   4 +
> >  9 files changed, 214 insertions(+), 9 deletions(-)
> >
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH-v11] drm/i915/huc: Add HuC fw loading support

[Anusha Srivatsa]

From: Peter Antoine 

The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.

HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.

v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon)
update huc_version number of format.
v3: rebased to drm-intel-nightly, changed the file name format to
match the one in the huc package.
Changed dev->dev_private to to_i915()
v4: moved function back to where it was.
change wait_for_atomic to wait_for.
v5: rebased + comment changes.
v7: rebased.
v8: rebased.
v9: rebased. Changed the year in the copyright message to reflect
the right year.Correct the comments,remove the unwanted WARN message,
replace drm_gem_object_unreference() with i915_gem_object_put().Make the
prototypes in intel_huc.h non-extern.
v10: rebased. Update the file construction done by HuC. It is similar to
GuC.Adopted the approach used in-
https://patchwork.freedesktop.org/patch/104355/ 
v11: Fix warnings. Remove old declaration.

Cc: Tvrtko Ursulin 
Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.h |   3 +
 drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
 drivers/gpu/drm/i915/intel_guc.h|   1 +
 drivers/gpu/drm/i915/intel_guc_loader.c |   6 +-
 drivers/gpu/drm/i915/intel_huc.h|  42 +
 drivers/gpu/drm/i915/intel_huc_loader.c | 269 
 7 files changed, 323 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3dea46a..cfea925 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -56,6 +56,7 @@ i915-y += i915_cmd_parser.o \
 
 # general-purpose microcontroller (GuC) support
 i915-y += intel_guc_loader.o \
+ intel_huc_loader.o \
  i915_guc_submission.o
 
 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c4a14de..3a6c412 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -56,6 +56,7 @@
 #include "intel_bios.h"
 #include "intel_dpll_mgr.h"
 #include "intel_guc.h"
+#include "intel_huc.h"
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
 
@@ -1791,6 +1792,7 @@ struct drm_i915_private {
 
struct intel_gvt *gvt;
 
+   struct intel_huc huc;
struct intel_guc guc;
 
struct intel_csr csr;
@@ -2607,6 +2609,7 @@ struct drm_i915_cmd_table {
 #define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
 #define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 #define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
+#define HAS_HUC_UCODE(dev) (HAS_GUC(dev))
 
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index a47e1e4..64e942a 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -61,9 +61,12 @@
 #define   DMA_ADDRESS_SPACE_GTT  (8 << 16)
 #define DMA_COPY_SIZE  _MMIO(0xc310)
 #define DMA_CTRL   _MMIO(0xc314)
+#define   HUC_UKERNEL(1<<9)
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   HUC_LOADING_AGENT_VCR  (0<<1)
+#define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
 
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 46990a0..338e803 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -184,6 +184,7 @@ extern const char *intel_uc_fw_status_repr(enum 
intel_uc_fw_status status);
 extern int intel_guc_suspend(struct drm_device *dev);
 extern int intel_guc_resume(struct drm_device *dev);
 void intel_uc_fw_fetch(struct drm_device *dev, struct intel_uc_fw *uc_fw);
+u32 guc_wopcm_size(struct drm_i915_private *dev_priv);
 
 /* i915_guc_submission.c */
 int i915_guc_submission_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 70b965d..7f3fdb0 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -309,7 +309,8 @@ static int 

Re: [Intel-gfx] [PATCH v2] drm/dp: Make space for null terminator in the DP device ID char array

[Pandiyan, Dhinakaran]

Adding Cc's.


On Mon, 2016-11-07 at 15:22 -0800, Dhinakaran Pandiyan wrote:
> The DP device identification string read from the DPCD registers is 6
> characters long at max. and we store it in a char array of the same length
> without space for the NULL terminator. Fix this by increasing the array
> size to 7 and initialize it to an empty string.
> 
> v2: Use %*pE format specifier (Jani)
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 3e6fe82..2d42760 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -544,7 +544,7 @@ void drm_dp_downstream_debug(struct seq_file *m,
>DP_DETAILED_CAP_INFO_AVAILABLE;
>   int clk;
>   int bpc;
> - char id[6];
> + char id[6] = "";
>   int len;
>   uint8_t rev[2];
>   int type = port_cap[0] & DP_DS_PORT_TYPE_MASK;
> @@ -584,7 +584,8 @@ void drm_dp_downstream_debug(struct seq_file *m,
>   }
>  
>   drm_dp_downstream_id(aux, id);
> - seq_printf(m, "\t\tID: %s\n", id);
> + len = strnlen(id, 6);
> + seq_printf(m, "\t\tID: %*pE\n", len, id);
>  
>   len = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, [0], 1);
>   if (len > 0)

___
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: cleanup use of INSTR_CLIENT_MASK

[Patchwork]

== Series Details ==

Series: drm/i915: cleanup use of INSTR_CLIENT_MASK
URL   : https://patchwork.freedesktop.org/series/15306/
State : success

== Summary ==

Series 15306v1 drm/i915: cleanup use of INSTR_CLIENT_MASK
https://patchwork.freedesktop.org/api/1.0/series/15306/revisions/1/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

2f21978cfd8984c79e4cbd77ce63d9f73fe226ef drm-intel-nightly: 
2016y-11m-14d-21h-23m-10s UTC integration manifest
ee0d578 drm/i915: cleanup use of INSTR_CLIENT_MASK

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2991/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: cleanup use of INSTR_CLIENT_MASK

[Chris Wilson]

On Mon, Nov 14, 2016 at 10:39:34PM +, Matthew Auld wrote:
> Doing cmd_header >> 29 to extract our 3-bit client value where we know
> cmd_header is a u32 shouldn't then also require the use of a mask. So
> remove the redundant operation and get rid of INSTR_CLIENT_MASK now that
> there are no longer any users.
> 
> Cc: Chris Wilson 
> Signed-off-by: Matthew Auld 
Reviewed-by: Chris Wilson 
-Chris

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

[Intel-gfx] [PATCH] drm/i915: cleanup use of INSTR_CLIENT_MASK

[Matthew Auld]

Doing cmd_header >> 29 to extract our 3-bit client value where we know
cmd_header is a u32 shouldn't then also require the use of a mask. So
remove the redundant operation and get rid of INSTR_CLIENT_MASK now that
there are no longer any users.

Cc: Chris Wilson 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 6 +++---
 drivers/gpu/drm/i915/i915_reg.h| 1 -
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index f5039f4..5eb7aac 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -559,7 +559,7 @@ static const struct drm_i915_reg_table hsw_blt_reg_tables[] 
= {
 
 static u32 gen7_render_get_cmd_length_mask(u32 cmd_header)
 {
-   u32 client = (cmd_header & INSTR_CLIENT_MASK) >> INSTR_CLIENT_SHIFT;
+   u32 client = cmd_header >> INSTR_CLIENT_SHIFT;
u32 subclient =
(cmd_header & INSTR_SUBCLIENT_MASK) >> INSTR_SUBCLIENT_SHIFT;
 
@@ -578,7 +578,7 @@ static u32 gen7_render_get_cmd_length_mask(u32 cmd_header)
 
 static u32 gen7_bsd_get_cmd_length_mask(u32 cmd_header)
 {
-   u32 client = (cmd_header & INSTR_CLIENT_MASK) >> INSTR_CLIENT_SHIFT;
+   u32 client = cmd_header >> INSTR_CLIENT_SHIFT;
u32 subclient =
(cmd_header & INSTR_SUBCLIENT_MASK) >> INSTR_SUBCLIENT_SHIFT;
u32 op = (cmd_header & INSTR_26_TO_24_MASK) >> INSTR_26_TO_24_SHIFT;
@@ -601,7 +601,7 @@ static u32 gen7_bsd_get_cmd_length_mask(u32 cmd_header)
 
 static u32 gen7_blt_get_cmd_length_mask(u32 cmd_header)
 {
-   u32 client = (cmd_header & INSTR_CLIENT_MASK) >> INSTR_CLIENT_SHIFT;
+   u32 client = cmd_header >> INSTR_CLIENT_SHIFT;
 
if (client == INSTR_MI_CLIENT)
return 0x3F;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3361d7f..60423a2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -294,7 +294,6 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
  * Instruction field definitions used by the command parser
  */
 #define INSTR_CLIENT_SHIFT  29
-#define INSTR_CLIENT_MASK   0xE000
 #define   INSTR_MI_CLIENT   0x0
 #define   INSTR_BC_CLIENT   0x2
 #define   INSTR_RC_CLIENT   0x3
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v3 14/14] drm/i915: Support explicit fencing for execbuf

[Rafael Antognolli]

Hi Chris,

I'm not sure you are waiting for this kind of feedback, but I've managed
to test this particular patch with Mesa, and I have some piglit tests
for it too. They are waiting for review, but at least the feature is
working as expected:

https://github.com/rantogno/piglit/commits/review/fences-v02

I used mesa and libdrm patches from more than a single set, but in case
you want to look they are here:

https://github.com/rantogno/mesa/commits/wip-fence
https://github.com/rantogno/libdrm/commits/wip-fence

And my kernel tree when I tested it:

https://github.com/rantogno/linux/commits/wip-fence

So in case it helps, you can add a

Tested-by: Rafael Antognolli 

PS: I can test it with this last series and everything more up to date,
if it will help to get this patch landed sooner.

Cheers,
Rafael

On Mon, Nov 14, 2016 at 08:57:03AM +, Chris Wilson wrote:
> Now that the user can opt-out of implicit fencing, we need to give them
> back control over the fencing. We employ sync_file to wrap our
> drm_i915_gem_request and provide an fd that userspace can merge with
> other sync_file fds and pass back to the kernel to wait upon before
> future execution.
> 
> Testcase: igt/gem_exec_fence
> Signed-off-by: Chris Wilson 
> Reviewed-by: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/Kconfig   |  1 +
>  drivers/gpu/drm/i915/i915_drv.c|  3 +-
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 54 
> +++---
>  include/uapi/drm/i915_drm.h| 35 ++-
>  4 files changed, 86 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index beed5c1d2cd7..bed81fe1d2a7 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -19,6 +19,7 @@ config DRM_I915
>   select INPUT if ACPI
>   select ACPI_VIDEO if ACPI
>   select ACPI_BUTTON if ACPI
> + select SYNC_FILE
>   help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 657c465a8d50..6fe7f41a5b5b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -344,6 +344,7 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>   case I915_PARAM_HAS_COHERENT_PHYS_GTT:
>   case I915_PARAM_HAS_EXEC_SOFTPIN:
>   case I915_PARAM_HAS_EXEC_ASYNC:
> + case I915_PARAM_HAS_EXEC_FENCE:
>   /* For the time being all of these are always true;
>* if some supported hardware does not have one of these
>* features this value needs to be provided from
> @@ -2533,7 +2534,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, drm_noop, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_GEM_INIT, drm_noop, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2_WR, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_reject_pin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_reject_pin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 781b5559f86e..facec610b55a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -28,6 +28,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -1597,6 +1598,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
> *data,
>   struct i915_execbuffer_params *params = _master;
>   const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
>   u32 dispatch_flags;
> + struct dma_fence *in_fence = NULL;
> + struct sync_file *out_fence = NULL;
> + int out_fence_fd = -1;
>   int ret;
>   bool need_relocs;
>  
> @@ -1640,6 +1644,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
> *data,
>   dispatch_flags |= I915_DISPATCH_RS;
>   }
>  
> + if (args->flags & I915_EXEC_FENCE_IN) {
> + in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
> + if (!in_fence) {
> + ret = -EINVAL;
> + goto pre_mutex_err;
> + }
> + }
> +
> + if (args->flags & I915_EXEC_FENCE_OUT) {
> + out_fence_fd = get_unused_fd_flags(O_CLOEXEC);
> + if (out_fence_fd < 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/dp/i915: Fix DP link rate math (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/dp/i915: Fix DP link rate math (rev2)
URL   : https://patchwork.freedesktop.org/series/15305/
State : success

== Summary ==

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


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

2f21978cfd8984c79e4cbd77ce63d9f73fe226ef drm-intel-nightly: 
2016y-11m-14d-21h-23m-10s UTC integration manifest
feb0aee drm/dp/i915: Fix DP link rate math

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2990/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math

[Dhinakaran Pandiyan]

We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec. are expressed in
Gbps/lane, which seems to have led to some confusion.

E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 216 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion

Using link clock frequency, like we do
Max. data rate = 54 kHz * 4 lanes = 216 kSymbols/s
Because, each symbol has 8 bit of data, this is 216 kBps
and there is no need to account for channel encoding here.

But, currently we do 54 kHz * 4 lanes * (8/10) = 1728000 kBps

Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * (bpp/8) to give the final result in
kBps

v2: Changed to DIV_ROUND_UP() and comment changes (Ville)

Signed-off-by: Dhinakaran Pandiyan 
---
Fixed a typo that snuck in.

 drivers/gpu/drm/i915/intel_dp.c | 35 +++
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f313c1..bdef314 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
*intel_dp)
return min(source_max, sink_max);
 }
 
-/*
- * The units on the numbers in the next two are... bizarre.  Examples will
- * make it clearer; this one parallels an example in the eDP spec.
- *
- * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
- *
- * 27 * 1 * 8 / 10 == 216000
- *
- * The actual data capacity of that configuration is 2.16Gbit/s, so the
- * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
- * or equivalently, kilopixels per second - so for 1680x1050R it'd be
- * 119000.  At 18bpp that's 2142000 kilobits per second.
- *
- * Thus the strange-looking division by 10 in intel_dp_link_required, to
- * get the result in decakilobits instead of kilobits.
- */
-
 static int
 intel_dp_link_required(int pixel_clock, int bpp)
 {
-   return (pixel_clock * bpp + 9) / 10;
+   /* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
+   return DIV_ROUND_UP(pixel_clock * bpp, 8);
 }
 
 static int
 intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 {
-   return (max_link_clock * max_lanes * 8) / 10;
+   /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
+* link rate that is generally expressed in Gbps. Since, 8 bits of data
+* is transmitted every LS_Clk per lane, there is no need to account for
+* the channel encoding that is done in the PHY layer here.
+*/
+
+   return max_link_clock * max_lanes;
 }
 
 static int
@@ -3573,7 +3563,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (val == 0)
break;
 
-   /* Value read is in kHz while drm clock is saved in 
deca-kHz */
+   /* Value read multiplied by 200kHz gives the per-lane
+* link rate in kHz. The source rates are, however,
+* stored in terms of LS_Clk kHz. The full conversion
+* back to symbols is
+* (val * 200kHz)*(8/10 ch. encoding)*(1/8 bit to Byte)
+*/
intel_dp->sink_rates[i] = (val * 200) / 10;
}
intel_dp->num_sink_rates = i;
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math

[Dhinakaran Pandiyan]

We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec. are expressed in
Gbps/lane, which seems to have led to some confusion.

E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 216 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion

Using link clock frequency, like we do
Max. data rate = 54 kHz * 4 lanes = 216 kSymbols/s
Because, each symbol has 8 bit of data, this is 216 kBps
and there is no need to account for channel encoding here.

But, currently we do 54 kHz * 4 lanes * (8/10) = 1728000 kBps

Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * (bpp/8) to give the final result in
kBps

v2: Changed to DIV_ROUND_UP() and comment changes (Ville)

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp.c | 35 +++
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f313c1..0c5d4bd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
*intel_dp)
return min(source_max, sink_max);
 }
 
-/*
- * The units on the numbers in the next two are... bizarre.  Examples will
- * make it clearer; this one parallels an example in the eDP spec.
- *
- * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
- *
- * 27 * 1 * 8 / 10 == 216000
- *
- * The actual data capacity of that configuration is 2.16Gbit/s, so the
- * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
- * or equivalently, kilopixels per second - so for 1680x1050R it'd be
- * 119000.  At 18bpp that's 2142000 kilobits per second.
- *
- * Thus the strange-looking division by 10 in intel_dp_link_required, to
- * get the result in decakilobits instead of kilobits.
- */
-
 static int
 intel_dp_link_required(int pixel_clock, int bpp)
 {
-   return (pixel_clock * bpp + 9) / 10;
+   /* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
+   return DIV_ROUND_UP(pixel_clk * bpp, 8);
 }
 
 static int
 intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 {
-   return (max_link_clock * max_lanes * 8) / 10;
+   /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
+* link rate that is generally expressed in Gbps. Since, 8 bits of data
+* is transmitted every LS_Clk per lane, there is no need to account for
+* the channel encoding that is done in the PHY layer here.
+*/
+
+   return max_link_clock * max_lanes;
 }
 
 static int
@@ -3573,7 +3563,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (val == 0)
break;
 
-   /* Value read is in kHz while drm clock is saved in 
deca-kHz */
+   /* Value read multiplied by 200kHz gives the per-lane
+* link rate in kHz. The source rates are, however,
+* stored in terms of LS_Clk kHz. The full conversion
+* back to symbols is
+* (val * 200kHz)*(8/10 ch. encoding)*(1/8 bit to Byte)
+*/
intel_dp->sink_rates[i] = (val * 200) / 10;
}
intel_dp->num_sink_rates = i;
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

[Dhinakaran Pandiyan]

Not validating the mode rate against max. link rate results in not pruning
invalid modes. For e.g, a HBR2 5.4 Gbps 2-lane configuration does not
support 4k@60Hz. But, we do not reject this mode.

So, make use of the helpers in intel_dp to validate mode data rate against
max. link data rate of a configuration.

v2: Renamed mode data rate local variable to be more explanatory.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp.c |  4 ++--
 drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++-
 drivers/gpu/drm/i915/intel_drv.h|  2 ++
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0c5d4bd..a7393e8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
*intel_dp)
return min(source_max, sink_max);
 }
 
-static int
+int
 intel_dp_link_required(int pixel_clock, int bpp)
 {
/* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
return DIV_ROUND_UP(pixel_clk * bpp, 8);
 }
 
-static int
+int
 intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 {
/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..2c557d9 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -335,7 +335,17 @@ static enum drm_mode_status
 intel_dp_mst_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
 {
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct intel_dp *intel_dp = intel_connector->mst_port;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+   int link_clock = intel_dp_max_link_rate(intel_dp);
+   int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+   int bpp = 24; /* MST uses fixed bpp */
+   int mode_data_rate;
+   int link_max_data_rate;
+
+   mode_data_rate = intel_dp_link_required(mode->clock, bpp);
+   link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
 
/* TODO - validate mode against available PBN for link */
if (mode->clock < 1)
@@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_H_ILLEGAL;
 
-   if (mode->clock > max_dotclk)
+   if (mode_data_rate > link_max_data_rate || mode->clock > max_dotclk)
return MODE_CLOCK_HIGH;
 
return MODE_OK;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2f3863..313419d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
 bool __intel_dp_read_desc(struct intel_dp *intel_dp,
  struct intel_dp_desc *desc);
 bool intel_dp_read_desc(struct intel_dp *intel_dp);
+int intel_dp_link_required(int pixel_clock, int bpp);
+int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
 
 /* intel_dp_aux_backlight.c */
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

[Pandiyan, Dhinakaran]

On Thu, 2016-11-10 at 15:32 -0800, Manasi Navare wrote:
> On Wed, Nov 09, 2016 at 09:32:30PM -0800, Dhinakaran Pandiyan wrote:
> > Not validating the the mode rate against link rate results not pruning
> > invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
> > support 4k @ 60Hz. But, we do not reject this mode currently.
> > 
> > So, make use of the helpers in intel_dp in validate mode rates against
> > max. data rate of a configuration.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c |  4 ++--
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++-
> >  drivers/gpu/drm/i915/intel_drv.h|  2 ++
> >  3 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 7a9e122..7a73e43 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp 
> > *intel_dp)
> > return min(source_max, sink_max);
> >  }
> >  
> > -static int
> > +int
> >  intel_dp_link_required(int pixel_clock, int bpp)
> >  {
> > /* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
> > return (pixel_clock * bpp + 7) / 8;
> >  }
> >  
> > -static int
> > +int
> >  intel_dp_max_data_rate(int max_link_clock, int max_lanes)
> >  {
> > /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 3ffbd69..38d2ce0 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -335,7 +335,17 @@ static enum drm_mode_status
> >  intel_dp_mst_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> >  {
> > +   struct intel_connector *intel_connector = to_intel_connector(connector);
> > +   struct intel_dp *intel_dp = intel_connector->mst_port;
> > int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
> > +   int link_clock = intel_dp_max_link_rate(intel_dp);
> > +   int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
> > +   int bpp = 24; /* MST uses fixed bpp */
> > +   int mode_rate;
> > +   int link_max_data_rate;
> 
> In the SST equivalent mode_valid function, this variable is named as
> max_rate, I think you should name it as max_rate as well for consistency.
> Other than that this looks good, we definitely need this for mode validation
> at an early stage.
> 
> Regards
> Manasi
> 

Well, one of the goals of Patch 1/2 is to reduce ambiguity that has led
to some confusing hacks. I prefer clarity over consistency and anyway
this variable is local to this function :)

-DK

> > +
> > +   link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
> > +   mode_rate = intel_dp_link_required(mode->clock, bpp);
> >  
> > /* TODO - validate mode against available PBN for link */
> > if (mode->clock < 1)
> > @@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
> > if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> > return MODE_H_ILLEGAL;
> >  
> > -   if (mode->clock > max_dotclk)
> > +   if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
> > return MODE_CLOCK_HIGH;
> >  
> > return MODE_OK;
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index c2f3863..313419d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> >  bool __intel_dp_read_desc(struct intel_dp *intel_dp,
> >   struct intel_dp_desc *desc);
> >  bool intel_dp_read_desc(struct intel_dp *intel_dp);
> > +int intel_dp_link_required(int pixel_clock, int bpp);
> > +int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> >  
> >  /* intel_dp_aux_backlight.c */
> >  int intel_dp_aux_init_backlight_funcs(struct intel_connector 
> > *intel_connector);
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH igt v4 06/13] igt/gem_exec_parse: init global parser_version in fixture

[Matthew Auld]

On 14 November 2016 at 20:51, Robert Bragg  wrote:
> This adds a static global int parser_version that can be referenced by
> all subtests without needing multiple GETPARAM requests.
>
> Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt v4 05/13] igt/gem_exec_parse: make global vars local to main()

[Matthew Auld]

On 14 November 2016 at 20:51, Robert Bragg  wrote:
> Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass

[Chris Wilson]

On Mon, Nov 14, 2016 at 09:16:08PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [CI,01/10] drm/i915: Give each sw_fence its own 
> lockclass
> URL   : https://patchwork.freedesktop.org/series/15303/
> State : warning
> 
> == Summary ==
> 
> Series 15303v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/15303/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (fi-skl-6770hq)

That darn lpscon
[   36.848874] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[   36.848916] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed 
on port B
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass

[Patchwork]

== Series Details ==

Series: series starting with [CI,01/10] drm/i915: Give each sw_fence its own 
lockclass
URL   : https://patchwork.freedesktop.org/series/15303/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:229  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

1ff093811f7fdf9b63a9fac336269f2083f1b433 drm-intel-nightly: 
2016y-11m-14d-18h-30m-41s UTC integration manifest
43d7bf2 drm/i915/scheduler: Boost priorities for flips
fad7db5 drm/i915: Store the execution priority on the context
18c62cb drm/i915/scheduler: Execute requests in order of priorities
0239870 drm/i915/scheduler: Record all dependencies upon request construction
b960818 drm/i915/scheduler: Signal the arrival of a new request
ba8b842 drm/i915: Remove engine->execlist_lock
bfc599f drm/i915: Defer transfer onto execution timeline to actual hw submission
3c07427 drm/i915: Split request submit/execute phase into two
0468d41 drm/i915: Create distinct lockclasses for execution vs user timelines
01db6b2 drm/i915: Give each sw_fence its own lockclass

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2989/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt v4 13/13] igt/gem_exec_parse: check oacontrol lri bad for >= v9

[Robert Bragg]

OACONTROL is no longer white listed in the command parser so this checks
at attempted LRI will be disallowed and (more importantly) checks that
userspace doesn't get an EINVAL error for an attempted OACONTROL LRI.
This is important becase Mesa application attempt OACONTROL LRIs while
initializing and will abort for any execbuf error.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 43f25ce..cc2103a 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -485,6 +485,22 @@ igt_main
/* dummy head pointer */
{ OASTATUS2, 0xff80, 0xdeadf000, 0xbeeff000 
}
};
+   struct test_lri v9_bad_lris[] = {
+   /* It's really important for us to check that
+* an LRI to OACONTROL doesn't result in an
+* EINVAL error because Mesa attempts writing
+* to OACONTROL to determine what extensions to
+* expose and will abort() for execbuffer()
+* errors.
+*
+* Mesa can gracefully recognise and handle the
+* LRI becoming a NOOP.
+*
+* The test values represent dummy context IDs
+* while leaving the OA unit disabled
+*/
+   { OACONTROL, 0xf000, 0xfeed, 0x31337000 
}
+   };
struct test_lri ok_lris[] = {
/* NB: [1:0] MBZ */
{ SO_WRITE_OFFSET_0, 0xfffc,
@@ -503,6 +519,15 @@ igt_main
 bad_lris + i, bad_lri_errno,
 bad_lris[i].init_val);
}
+
+   if (parser_version >= 9) {
+   for (int i = 0; i < ARRAY_SIZE(v9_bad_lris); 
i++) {
+   test_lri(fd, handle,
+v9_bad_lris + i,
+0,
+v9_bad_lris[i].init_val);
+   }
+   }
}
 
igt_fixture {
-- 
2.10.1

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

[Intel-gfx] [PATCH igt v4 11/13] igt/gem_exec_parse: update hsw_load_register_reg for v >= 8

[Robert Bragg]

This updates the checking of disallowed loads to set a distinguishable
value before the load and explicitly check the load was a NOOP by
reading back the final value.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 5c67e12..2bc6340 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -341,6 +341,7 @@ static void hsw_load_register_reg(void)
};
int fd;
uint32_t handle;
+   int bad_lrr_errno = parser_version >= 8 ? 0 : -EINVAL;
 
/* Open again to get a non-master file descriptor */
fd = drm_open_driver(DRIVER_INTEL);
@@ -371,10 +372,21 @@ static void hsw_load_register_reg(void)
}
 
for (int i = 0 ; i < ARRAY_SIZE(disallowed_regs); i++) {
+   exec_batch(fd, handle, init_gpr0, sizeof(init_gpr0),
+  I915_EXEC_RENDER,
+  0);
+   exec_batch_patched(fd, handle,
+  store_gpr0, sizeof(store_gpr0),
+  2 * sizeof(uint32_t), /* reloc */
+  0xabcdabc0);
do_lrr[1] = disallowed_regs[i];
exec_batch(fd, handle, do_lrr, sizeof(do_lrr),
   I915_EXEC_RENDER,
-  -EINVAL);
+  bad_lrr_errno);
+   exec_batch_patched(fd, handle,
+  store_gpr0, sizeof(store_gpr0),
+  2 * sizeof(uint32_t), /* reloc */
+  0xabcdabc0);
}
 
close(fd);
-- 
2.10.1

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

[Intel-gfx] [PATCH igt v4 10/13] igt/gem_exec_parse: update cmd-crossing-page for >= v8

[Robert Bragg]

Since an access violation won't return an error to userspace for v >= 8
of the command parser this updates the cmd-crossing-page test to
explicitly read back from SO_WRITE_OFFSET[0] to see that the command
wasn't squashed to a NOOP.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index d5769e4..5c67e12 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -531,14 +531,25 @@ igt_main
igt_subtest("cmd-crossing-page") {
uint32_t lri_ok[] = {
MI_LOAD_REGISTER_IMM,
-   0x5280, /* allowed register address 
(SO_WRITE_OFFSET[0]) */
-   0x1,
+   SO_WRITE_OFFSET_0, /* allowed register address */
+   0xdcbaabc0, /* [1:0] MBZ */
+   MI_BATCH_BUFFER_END,
+   };
+   uint32_t store_reg[] = {
+   MI_STORE_REGISTER_MEM | (3 - 2),
+   SO_WRITE_OFFSET_0,
+   0, /* reloc */
MI_BATCH_BUFFER_END,
};
exec_split_batch(fd,
 lri_ok, sizeof(lri_ok),
 I915_EXEC_RENDER,
 0);
+   exec_batch_patched(fd, handle,
+  store_reg,
+  sizeof(store_reg),
+  2 * sizeof(uint32_t), /* reloc */
+  0xdcbaabc0);
}
 
igt_subtest("oacontrol-tracking") {
-- 
2.10.1

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

[Intel-gfx] [PATCH igt v4 07/13] igt/gem_exec_parse: req. v < 9 for oacontrol tracking test

[Robert Bragg]

This limits testing the oacontrol tracking (required pairing of oa
enable/disable per batch buffer) to version <= 8 of the command parser.

Version 9 of the command parser removes all special handling for
OACONTROL which is now going to be managed by i915-perf and not
programmed from userspace.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 9e57ff5..6dc9998 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -551,6 +551,9 @@ igt_main
0x31337000,
MI_BATCH_BUFFER_END,
};
+
+   igt_require(parser_version < 9);
+
exec_batch(fd, handle,
   lri_ok, sizeof(lri_ok),
   I915_EXEC_RENDER,
-- 
2.10.1

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

[Intel-gfx] [PATCH igt v4 12/13] igt/gem_exec_parse: update registers test for v >= 8

[Robert Bragg]

This combines some parts of the recently added store_lri test with the
registers test to be able to first load a distinguishable value before
the LRI and explicitly read back the register to determine if the
command succeeded or was a NOOP.

For now though we won't look at OACONTROL without checking for version 9
of the command parser.

This updates the 'bad' test to check the OASTATUS2 register so that we
can explicitly read back from the register to check it becomes a NOOP.

This adds a struct test_lri for associating a mask with the init/test
values so we ignore things like hw status bits that might interfere
with the result.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 94 ++
 1 file changed, 49 insertions(+), 45 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 2bc6340..43f25ce 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -35,6 +35,7 @@
 #endif
 
 #define DERRMR 0x44050
+#define OASTATUS2 0x2368
 #define OACONTROL 0x2360
 #define SO_WRITE_OFFSET_0 0x5280
 
@@ -253,27 +254,35 @@ static void exec_batch_chained(int fd, uint32_t cmd_bo, 
uint32_t *cmds,
gem_close(fd, target_bo);
 }
 
-static void stray_lri(int fd, uint32_t handle)
+/* Be careful to take into account what register bits we can store and read
+ * from...
+ */
+struct test_lri {
+   uint32_t reg, read_mask, init_val, test_val;
+};
+
+static void
+test_lri(int fd, uint32_t handle,
+struct test_lri *test, int expected_errno, uint32_t expect)
 {
-   /* Ideally this would test all once whitelisted registers */
uint32_t lri[] = {
MI_LOAD_REGISTER_IMM,
-   OACONTROL,
-   0x31337000,
+   test->reg,
+   test->test_val,
MI_BATCH_BUFFER_END,
};
-   int err;
 
-   igt_assert_eq_u32(intel_register_read(OACONTROL), 0xdeadbeef);
+   intel_register_write(test->reg, test->init_val);
 
-   err = __exec_batch(fd, handle, lri, sizeof(lri), I915_EXEC_RENDER);
-   if (err == -EINVAL)
-   return;
-
-   igt_assert_eq(err, 0);
+   exec_batch(fd, handle,
+  lri, sizeof(lri),
+  I915_EXEC_RENDER,
+  expected_errno);
gem_sync(fd, handle);
 
-   igt_assert_eq_u32(intel_register_read(OACONTROL), 0xdeadbeef);
+   igt_assert_eq_u32((intel_register_read(test->reg) &
+  test->read_mask),
+ expect);
 }
 
 static void test_allocations(int fd)
@@ -462,50 +471,45 @@ igt_main
   -EINVAL);
}
 
+   igt_subtest("basic-allocation") {
+   test_allocations(fd);
+   }
+
igt_subtest_group {
igt_fixture {
intel_register_access_init(intel_get_pci_device(), 0);
-
-   intel_register_write(OACONTROL, 0xdeadbeef);
-   igt_assert_eq_u32(intel_register_read(OACONTROL), 
0xdeadbeef);
}
 
-   igt_subtest("basic-stray-lri")
-   stray_lri(fd, handle);
+   igt_subtest("registers") {
+   struct test_lri bad_lris[] = {
+   /* dummy head pointer */
+   { OASTATUS2, 0xff80, 0xdeadf000, 0xbeeff000 
}
+   };
+   struct test_lri ok_lris[] = {
+   /* NB: [1:0] MBZ */
+   { SO_WRITE_OFFSET_0, 0xfffc,
+ 0xabcdabc0, 0xbeefbee0 }
+   };
+   int bad_lri_errno = parser_version >= 8 ? 0 : -EINVAL;
+
+   for (int i = 0; i < ARRAY_SIZE(ok_lris); i++) {
+   test_lri(fd, handle,
+ok_lris + i, 0,
+ok_lris[i].test_val);
+   }
+
+   for (int i = 0; i < ARRAY_SIZE(bad_lris); i++) {
+   test_lri(fd, handle,
+bad_lris + i, bad_lri_errno,
+bad_lris[i].init_val);
+   }
+   }
 
igt_fixture {
-   intel_register_write(OACONTROL, 0);
intel_register_access_fini();
}
}
 
-   igt_subtest("basic-allocation") {
-   test_allocations(fd);
-   }
-
-   igt_subtest("registers") {
-   uint32_t lri_bad[] = {
-   MI_LOAD_REGISTER_IMM,
-   0, /* disallowed register address */
-   0x1200,
-   MI_BATCH_BUFFER_END,
-   };
-   

[Intel-gfx] [PATCH igt v4 08/13] igt/gem_exec_parse: make basic-rejected version agnostic

[Robert Bragg]

This adapts the basic-rejected test to focus on invalid commands that
will result in an EINVAL errno being returned to userspace even with the
upcoming version 8 parser change to stop reporting access violations as
EINVAL errors.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 6dc9998..03e4d0e 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -42,6 +42,10 @@
 #define HSW_CS_GPR0 HSW_CS_GPR(0)
 #define HSW_CS_GPR1 HSW_CS_GPR(1)
 
+/* To help craft commands known to be invalid across all engines */
+#define INSTR_CLIENT_SHIFT 29
+#define   INSTR_INVALID_CLIENT  0x7
+
 #define MI_LOAD_REGISTER_REG (0x2a << 23)
 #define MI_STORE_REGISTER_MEM (0x24 << 23)
 #define MI_ARB_ON_OFF (0x8 << 23)
@@ -411,33 +415,38 @@ igt_main
}
 
igt_subtest("basic-rejected") {
-   uint32_t arb_on_off[] = {
-   MI_ARB_ON_OFF,
+   uint32_t invalid_cmd[] = {
+   INSTR_INVALID_CLIENT << INSTR_CLIENT_SHIFT,
MI_BATCH_BUFFER_END,
};
-   uint32_t display_flip[] = {
-   MI_DISPLAY_FLIP,
-   0, 0, 0,
+   uint32_t invalid_set_context[] = {
+   MI_SET_CONTEXT | 32, /* invalid length */
MI_BATCH_BUFFER_END,
-   0
};
exec_batch(fd, handle,
-  arb_on_off, sizeof(arb_on_off),
+  invalid_cmd, sizeof(invalid_cmd),
   I915_EXEC_RENDER,
   -EINVAL);
exec_batch(fd, handle,
-  arb_on_off, sizeof(arb_on_off),
+  invalid_cmd, sizeof(invalid_cmd),
   I915_EXEC_BSD,
   -EINVAL);
+   if (gem_has_blt(fd)) {
+   exec_batch(fd, handle,
+  invalid_cmd, sizeof(invalid_cmd),
+  I915_EXEC_BLT,
+  -EINVAL);
+   }
if (gem_has_vebox(fd)) {
exec_batch(fd, handle,
-  arb_on_off, sizeof(arb_on_off),
+  invalid_cmd, sizeof(invalid_cmd),
   I915_EXEC_VEBOX,
   -EINVAL);
}
+
exec_batch(fd, handle,
-  display_flip, sizeof(display_flip),
-  I915_EXEC_BLT,
+  invalid_set_context, sizeof(invalid_set_context),
+  I915_EXEC_RENDER,
   -EINVAL);
}
 
-- 
2.10.1

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

[Intel-gfx] [PATCH igt v4 09/13] igt/gem_exec_parse: update bitmasks test for v >=8

[Robert Bragg]

With v8 of the command parser (where we won't get an EINVAL for an
access violation) this updates the bitmasks test to explicitly confirm
that the command became a NOOP by reading back from where the QW_WRITE
would have otherwise landed.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 03e4d0e..d5769e4 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -504,10 +504,20 @@ igt_main
0,
MI_BATCH_BUFFER_END,
};
-   exec_batch(fd, handle,
-  pc, sizeof(pc),
-  I915_EXEC_RENDER,
-  -EINVAL);
+   if (parser_version >= 8) {
+   /* Expect to read back zero since the command should be
+* squashed to a NOOP
+*/
+   exec_batch_patched(fd, handle,
+  pc, sizeof(pc),
+  8, /* patch offset, */
+  0x0);
+   } else {
+   exec_batch(fd, handle,
+  pc, sizeof(pc),
+  I915_EXEC_RENDER,
+  -EINVAL);
+   }
}
 
igt_subtest("batch-without-end") {
-- 
2.10.1

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

[Intel-gfx] [PATCH igt v4 04/13] igt/gem_exec_parse: update hsw_load_register_reg

[Robert Bragg]

This generalises hsw_load_register_reg to loop through an array of
allowed and disallowed registers and to use the exec_batch[_patched]
utilities.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 137 +++--
 1 file changed, 64 insertions(+), 73 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 7a9dc82..dcf39a2 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -34,8 +34,9 @@
 #define I915_PARAM_CMD_PARSER_VERSION   28
 #endif
 
-#define OACONTROL 0x2360
 #define DERRMR 0x44050
+#define OACONTROL 0x2360
+#define SO_WRITE_OFFSET_0 0x5280
 
 #define HSW_CS_GPR(n) (0x2600 + 8*(n))
 #define HSW_CS_GPR0 HSW_CS_GPR(0)
@@ -65,8 +66,8 @@ static int command_parser_version(int fd)
return -1;
 }
 
-static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
-  int size, int patch_offset, uint64_t 
expected_value)
+static uint64_t __exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
+int size, int patch_offset)
 {
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 obj[2];
@@ -100,9 +101,19 @@ static void exec_batch_patched(int fd, uint32_t cmd_bo, 
uint32_t *cmds,
gem_sync(fd, cmd_bo);
 
gem_read(fd,target_bo, 0, _value, sizeof(actual_value));
-   igt_assert_eq(expected_value, actual_value);
 
gem_close(fd, target_bo);
+
+   return actual_value;
+}
+
+static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
+  int size, int patch_offset,
+  uint64_t expected_value)
+{
+   igt_assert_eq(__exec_batch_patched(fd, cmd_bo, cmds,
+  size, patch_offset),
+ expected_value);
 }
 
 static int __exec_batch(int fd, uint32_t cmd_bo, uint32_t *cmds,
@@ -295,31 +306,36 @@ static void test_allocations(int fd)
 
 static void hsw_load_register_reg(void)
 {
-   uint32_t buf[16] = {
-   MI_LOAD_REGISTER_IMM | (5 - 2),
+   uint32_t init_gpr0[16] = {
+   MI_LOAD_REGISTER_IMM | (3 - 2),
HSW_CS_GPR0,
-   0xabcdabcd,
-   HSW_CS_GPR1,
-   0xdeadbeef,
-
+   0xabcdabc0, /* leave [1:0] zero */
+   MI_BATCH_BUFFER_END,
+   };
+   uint32_t store_gpr0[16] = {
MI_STORE_REGISTER_MEM | (3 - 2),
-   HSW_CS_GPR1,
-   0, /* address0 */
-
-   MI_LOAD_REGISTER_REG | (3 - 2),
HSW_CS_GPR0,
-   HSW_CS_GPR1,
-
-   MI_STORE_REGISTER_MEM | (3 - 2),
-   HSW_CS_GPR1,
-   4, /* address1 */
-
+   0, /* reloc*/
MI_BATCH_BUFFER_END,
};
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 obj[2];
-   struct drm_i915_gem_relocation_entry reloc[2];
+   uint32_t do_lrr[16] = {
+   MI_LOAD_REGISTER_REG | (3 - 2),
+   0, /* [1] = src */
+   HSW_CS_GPR0, /* dst */
+   MI_BATCH_BUFFER_END,
+   };
+   uint32_t allowed_regs[] = {
+   HSW_CS_GPR1,
+   SO_WRITE_OFFSET_0,
+   };
+   uint32_t disallowed_regs[] = {
+   0,
+   OACONTROL, /* filtered */
+   DERRMR, /* master only */
+   0x2038, /* RING_START: invalid */
+   };
int fd;
+   uint32_t handle;
 
/* Open again to get a non-master file descriptor */
fd = drm_open_driver(DRIVER_INTEL);
@@ -327,59 +343,34 @@ static void hsw_load_register_reg(void)
igt_require(IS_HASWELL(intel_get_drm_devid(fd)));
igt_require(command_parser_version(fd) >= 7);
 
-   memset(obj, 0, sizeof(obj));
-   obj[0].handle = gem_create(fd, 4096);
-   obj[1].handle = gem_create(fd, 4096);
-   gem_write(fd, obj[1].handle, 0, buf, sizeof(buf));
+   handle = gem_create(fd, 4096);
 
-   memset(reloc, 0, sizeof(reloc));
-   reloc[0].offset = 7*sizeof(uint32_t);
-   reloc[0].target_handle = obj[0].handle;
-   reloc[0].delta = 0;
-   reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
-   reloc[0].write_domain = I915_GEM_DOMAIN_COMMAND;
-   reloc[1].offset = 13*sizeof(uint32_t);
-   reloc[1].target_handle = obj[0].handle;
-   reloc[1].delta = sizeof(uint32_t);
-   reloc[1].read_domains = I915_GEM_DOMAIN_COMMAND;
-   reloc[1].write_domain = I915_GEM_DOMAIN_COMMAND;
-   obj[1].relocs_ptr = (uintptr_t)
-   obj[1].relocation_count = 2;
+   for (int i = 0 ; i < ARRAY_SIZE(allowed_regs); i++) {
+   uint32_t var;
 
-   memset(, 0, sizeof(execbuf));
-   execbuf.buffers_ptr = (uintptr_t)obj;
-   execbuf.buffer_count = 2;
- 

[Intel-gfx] [PATCH igt v4 06/13] igt/gem_exec_parse: init global parser_version in fixture

[Robert Bragg]

This adds a static global int parser_version that can be referenced by
all subtests without needing multiple GETPARAM requests.

Signed-off-by: Robert Bragg 
---
 tests/gem_exec_parse.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index ebcd092..9e57ff5 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -51,6 +51,7 @@
 #define   PIPE_CONTROL_QW_WRITE(1<<14)
 #define   PIPE_CONTROL_LRI_POST_OP (1<<23)
 
+static int parser_version;
 
 static int command_parser_version(int fd)
 {
@@ -341,7 +342,7 @@ static void hsw_load_register_reg(void)
fd = drm_open_driver(DRIVER_INTEL);
 
igt_require(IS_HASWELL(intel_get_drm_devid(fd)));
-   igt_require(command_parser_version(fd) >= 7);
+   igt_require(parser_version >= 7);
 
handle = gem_create(fd, 4096);
 
@@ -381,16 +382,10 @@ igt_main
int fd;
 
igt_fixture {
-   int parser_version = 0;
-drm_i915_getparam_t gp;
-   int rc;
-
fd = drm_open_driver(DRIVER_INTEL);
 
-   gp.param = I915_PARAM_CMD_PARSER_VERSION;
-   gp.value = _version;
-   rc = drmIoctl(fd, DRM_IOCTL_I915_GETPARAM, );
-   igt_require(!rc && parser_version > 0);
+   parser_version = command_parser_version(fd);
+   igt_require(parser_version != -1);
 
igt_require(gem_uses_ppgtt(fd));
 
-- 
2.10.1

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

[Intel-gfx] [PATCH igt v4 05/13] igt/gem_exec_parse: make global vars local to main()

[Robert Bragg]

Signed-off-by: Robert Bragg 
---
 tests/gem_exec_parse.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index dcf39a2..ebcd092 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -375,11 +375,11 @@ static void hsw_load_register_reg(void)
close(fd);
 }
 
-static uint32_t handle;
-static int fd;
-
 igt_main
 {
+   uint32_t handle;
+   int fd;
+
igt_fixture {
int parser_version = 0;
 drm_i915_getparam_t gp;
-- 
2.10.1

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

[Intel-gfx] [PATCH igt v4 03/13] igt/gem_exec_parse: move hsw_load_register_reg down

[Robert Bragg]

No functional change, just moving hsw_load_regster_reg test code down
below the execbuf utilities in preparation for updating to use them.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 182 -
 1 file changed, 91 insertions(+), 91 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index c81bbc7..7a9dc82 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -65,97 +65,6 @@ static int command_parser_version(int fd)
return -1;
 }
 
-static void hsw_load_register_reg(void)
-{
-   uint32_t buf[16] = {
-   MI_LOAD_REGISTER_IMM | (5 - 2),
-   HSW_CS_GPR0,
-   0xabcdabcd,
-   HSW_CS_GPR1,
-   0xdeadbeef,
-
-   MI_STORE_REGISTER_MEM | (3 - 2),
-   HSW_CS_GPR1,
-   0, /* address0 */
-
-   MI_LOAD_REGISTER_REG | (3 - 2),
-   HSW_CS_GPR0,
-   HSW_CS_GPR1,
-
-   MI_STORE_REGISTER_MEM | (3 - 2),
-   HSW_CS_GPR1,
-   4, /* address1 */
-
-   MI_BATCH_BUFFER_END,
-   };
-   struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 obj[2];
-   struct drm_i915_gem_relocation_entry reloc[2];
-   int fd;
-
-   /* Open again to get a non-master file descriptor */
-   fd = drm_open_driver(DRIVER_INTEL);
-
-   igt_require(IS_HASWELL(intel_get_drm_devid(fd)));
-   igt_require(command_parser_version(fd) >= 7);
-
-   memset(obj, 0, sizeof(obj));
-   obj[0].handle = gem_create(fd, 4096);
-   obj[1].handle = gem_create(fd, 4096);
-   gem_write(fd, obj[1].handle, 0, buf, sizeof(buf));
-
-   memset(reloc, 0, sizeof(reloc));
-   reloc[0].offset = 7*sizeof(uint32_t);
-   reloc[0].target_handle = obj[0].handle;
-   reloc[0].delta = 0;
-   reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
-   reloc[0].write_domain = I915_GEM_DOMAIN_COMMAND;
-   reloc[1].offset = 13*sizeof(uint32_t);
-   reloc[1].target_handle = obj[0].handle;
-   reloc[1].delta = sizeof(uint32_t);
-   reloc[1].read_domains = I915_GEM_DOMAIN_COMMAND;
-   reloc[1].write_domain = I915_GEM_DOMAIN_COMMAND;
-   obj[1].relocs_ptr = (uintptr_t)
-   obj[1].relocation_count = 2;
-
-   memset(, 0, sizeof(execbuf));
-   execbuf.buffers_ptr = (uintptr_t)obj;
-   execbuf.buffer_count = 2;
-   execbuf.batch_len = sizeof(buf);
-   execbuf.flags = I915_EXEC_RENDER;
-   gem_execbuf(fd, );
-   gem_close(fd, obj[1].handle);
-
-   gem_read(fd, obj[0].handle, 0, buf, 2*sizeof(buf[0]));
-   igt_assert_eq_u32(buf[0], 0xdeadbeef); /* before copy */
-   igt_assert_eq_u32(buf[1], 0xabcdabcd); /* after copy */
-
-   /* Now a couple of negative tests that should be filtered */
-   execbuf.buffer_count = 1;
-   execbuf.batch_len = 4*sizeof(buf[0]);
-
-   buf[0] = MI_LOAD_REGISTER_REG | (3 - 2);
-   buf[1] = HSW_CS_GPR0;
-   buf[2] = 0;
-   buf[3] = MI_BATCH_BUFFER_END;
-   gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
-   igt_assert_eq(__gem_execbuf(fd, ), -EINVAL);
-
-   buf[2] = OACONTROL; /* filtered */
-   gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
-   igt_assert_eq(__gem_execbuf(fd, ), -EINVAL);
-
-   buf[2] = DERRMR; /* master only */
-   gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
-   igt_assert_eq(__gem_execbuf(fd, ), -EINVAL);
-
-   buf[2] = 0x2038; /* RING_START: invalid */
-   gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
-   igt_assert_eq(__gem_execbuf(fd, ), -EINVAL);
-
-   close(fd);
-}
-
 static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
   int size, int patch_offset, uint64_t 
expected_value)
 {
@@ -384,6 +293,97 @@ static void test_allocations(int fd)
}
 }
 
+static void hsw_load_register_reg(void)
+{
+   uint32_t buf[16] = {
+   MI_LOAD_REGISTER_IMM | (5 - 2),
+   HSW_CS_GPR0,
+   0xabcdabcd,
+   HSW_CS_GPR1,
+   0xdeadbeef,
+
+   MI_STORE_REGISTER_MEM | (3 - 2),
+   HSW_CS_GPR1,
+   0, /* address0 */
+
+   MI_LOAD_REGISTER_REG | (3 - 2),
+   HSW_CS_GPR0,
+   HSW_CS_GPR1,
+
+   MI_STORE_REGISTER_MEM | (3 - 2),
+   HSW_CS_GPR1,
+   4, /* address1 */
+
+   MI_BATCH_BUFFER_END,
+   };
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry reloc[2];
+   int fd;
+
+   /* Open again to get a non-master file descriptor */
+   fd = drm_open_driver(DRIVER_INTEL);
+
+   

[Intel-gfx] [PATCH igt v4 01/13] igt/perf: add i915 perf stream tests for Haswell

[Robert Bragg]

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/Makefile.sources |1 +
 tests/perf.c   | 2373 
 2 files changed, 2374 insertions(+)
 create mode 100644 tests/perf.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 65e0792..a818963 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -214,6 +214,7 @@ TESTS_progs = \
kms_pwrite_crc \
kms_sink_crc_basic \
prime_udl \
+   perf \
$(NULL)
 
 # IMPORTANT: The ZZ_ tests need to be run last!
diff --git a/tests/perf.c b/tests/perf.c
new file mode 100644
index 000..1aafca9
--- /dev/null
+++ b/tests/perf.c
@@ -0,0 +1,2373 @@
+/*
+ * Copyright © 2016 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "igt.h"
+#include "drm.h"
+
+IGT_TEST_DESCRIPTION("Test the i915 perf metrics streaming interface");
+
+#define GEN6_MI_REPORT_PERF_COUNT ((0x28 << 23) | (3 - 2))
+
+#define GFX_OP_PIPE_CONTROL ((3 << 29) | (3 << 27) | (2 << 24))
+#define PIPE_CONTROL_CS_STALL (1 << 20)
+#define PIPE_CONTROL_GLOBAL_SNAPSHOT_COUNT_RESET   (1 << 19)
+#define PIPE_CONTROL_TLB_INVALIDATE (1 << 18)
+#define PIPE_CONTROL_SYNC_GFDT   (1 << 17)
+#define PIPE_CONTROL_MEDIA_STATE_CLEAR  (1 << 16)
+#define PIPE_CONTROL_NO_WRITE (0 << 14)
+#define PIPE_CONTROL_WRITE_IMMEDIATE(1 << 14)
+#define PIPE_CONTROL_WRITE_DEPTH_COUNT  (2 << 14)
+#define PIPE_CONTROL_WRITE_TIMESTAMP(3 << 14)
+#define PIPE_CONTROL_DEPTH_STALL   (1 << 13)
+#define PIPE_CONTROL_RENDER_TARGET_FLUSH (1 << 12)
+#define PIPE_CONTROL_INSTRUCTION_INVALIDATE (1 << 11)
+#define PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE   (1 << 10) /* GM45+ only */
+#define PIPE_CONTROL_ISP_DIS   (1 << 9)
+#define PIPE_CONTROL_INTERRUPT_ENABLE   (1 << 8)
+#define PIPE_CONTROL_FLUSH_ENABLE   (1 << 7) /* Gen7+ only */
+/* GT */
+#define PIPE_CONTROL_DATA_CACHE_INVALIDATE  (1 << 5)
+#define PIPE_CONTROL_VF_CACHE_INVALIDATE   (1 << 4)
+#define PIPE_CONTROL_CONST_CACHE_INVALIDATE (1 << 3)
+#define PIPE_CONTROL_STATE_CACHE_INVALIDATE (1 << 2)
+#define PIPE_CONTROL_STALL_AT_SCOREBOARD   (1 << 1)
+#define PIPE_CONTROL_DEPTH_CACHE_FLUSH   (1 << 0)
+#define PIPE_CONTROL_PPGTT_WRITE   (0 << 2)
+#define PIPE_CONTROL_GLOBAL_GTT_WRITE   (1 << 2)
+
+#define NSEC_PER_SEC 10ull
+
+/* Temporarily copy i915-perf uapi here to avoid a dependency on libdrm's
+ * i915_drm.h copy being updated with the i915-perf interface before this
+ * test can land in i-g-t.
+ *
+ * TODO: remove this once the interface lands in libdrm
+ */
+#ifndef DRM_I915_PERF_OPEN
+#define DRM_I915_PERF_OPEN 0x36
+#define DRM_IOCTL_I915_PERF_OPEN   DRM_IOW(DRM_COMMAND_BASE + 
DRM_I915_PERF_OPEN, struct drm_i915_perf_open_param)
+
+enum drm_i915_oa_format {
+   I915_OA_FORMAT_A13 = 1,
+   I915_OA_FORMAT_A29,
+   I915_OA_FORMAT_A13_B8_C8,
+   I915_OA_FORMAT_B4_C8,
+   I915_OA_FORMAT_A45_B8_C8,
+   I915_OA_FORMAT_B4_C8_A16,
+   I915_OA_FORMAT_C4_B8,
+
+   I915_OA_FORMAT_MAX /* non-ABI */
+};
+
+enum drm_i915_perf_property_id {
+   DRM_I915_PERF_PROP_CTX_HANDLE = 1,
+   DRM_I915_PERF_PROP_SAMPLE_OA,
+   DRM_I915_PERF_PROP_OA_METRICS_SET,
+   DRM_I915_PERF_PROP_OA_FORMAT,
+   DRM_I915_PERF_PROP_OA_EXPONENT,
+
+   DRM_I915_PERF_PROP_MAX /* non-ABI */
+};
+
+struct drm_i915_perf_open_param {
+   __u32 flags;
+#define I915_PERF_FLAG_FD_CLOEXEC  (1<<0)
+#define I915_PERF_FLAG_FD_NONBLOCK (1<<1)
+#define I915_PERF_FLAG_DISABLED(1<<2)
+
+   __u32 num_properties;
+   __u64 properties_ptr;
+};
+
+#define 

[Intel-gfx] [PATCH igt v4 00/13] corresponding changes for i915-perf interface

[Robert Bragg]

The i915-perf series affects the command parser and itself includes new uapi
which these i-g-t changes try to cover.

This update follows up on review from both Matt and Chris.

A minor change I ended up making was to rename the hsw_oa_formats[] array to
oa_formats[] indexed by the format ID so the test could more easily get to the
C counter offset for a given format which I think helps make test_oa_exponents
clearer, avoiding using '224' with a /* C offset */ comment. The same array may
be extended later for testing gen8+ so I've removed the hsw_ prefix for now.

I noticed the existing handle and fd global variables could be made local to
main() and so added a minor patch for that.

perf.c no longer depends on the i915_drm.h copy in libdrm including the i915
perf interface since the test itself includes a guarded copy of the new uapi
for now.

- Robert

Robert Bragg (13):
  igt/perf: add i915 perf stream tests for Haswell
  igt/gem_exec_parse: some minor cleanups
  igt/gem_exec_parse: move hsw_load_register_reg down
  igt/gem_exec_parse: update hsw_load_register_reg
  igt/gem_exec_parse: make global vars local to main()
  igt/gem_exec_parse: init global parser_version in fixture
  igt/gem_exec_parse: req. v < 9 for oacontrol tracking test
  igt/gem_exec_parse: make basic-rejected version agnostic
  igt/gem_exec_parse: update bitmasks test for v >=8
  igt/gem_exec_parse: update cmd-crossing-page for >= v8
  igt/gem_exec_parse: update hsw_load_register_reg for v >= 8
  igt/gem_exec_parse: update registers test for v >= 8
  igt/gem_exec_parse: check oacontrol lri bad for >= v9

 tests/Makefile.sources |1 +
 tests/gem_exec_parse.c |  568 ++--
 tests/perf.c   | 2373 
 3 files changed, 2656 insertions(+), 286 deletions(-)
 create mode 100644 tests/perf.c

-- 
2.10.1

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

[Intel-gfx] [PATCH igt v4 02/13] igt/gem_exec_parse: some minor cleanups

[Robert Bragg]

This normalizes the execbuf utilities in this file to all use memset to
clear obj, reloc and execbuf structures and set them up in the same
order. As I was debugging some unpredictable test failures I was getting
unsure that all these structures were being fully initialized.

The same I915_GEM_DOMAIN_COMMAND domain is now used with all relocs.

The register/command defines have been moved to the top of the file to
be available to all tests/utilities.

The handle + fd variables are now static.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 tests/gem_exec_parse.c | 196 +
 1 file changed, 66 insertions(+), 130 deletions(-)

diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 2739b2c..c81bbc7 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -37,6 +37,20 @@
 #define OACONTROL 0x2360
 #define DERRMR 0x44050
 
+#define HSW_CS_GPR(n) (0x2600 + 8*(n))
+#define HSW_CS_GPR0 HSW_CS_GPR(0)
+#define HSW_CS_GPR1 HSW_CS_GPR(1)
+
+#define MI_LOAD_REGISTER_REG (0x2a << 23)
+#define MI_STORE_REGISTER_MEM (0x24 << 23)
+#define MI_ARB_ON_OFF (0x8 << 23)
+#define MI_DISPLAY_FLIP ((0x14 << 23) | 1)
+
+#define GFX_OP_PIPE_CONTROL((0x3<<29)|(0x3<<27)|(0x2<<24)|2)
+#define   PIPE_CONTROL_QW_WRITE(1<<14)
+#define   PIPE_CONTROL_LRI_POST_OP (1<<23)
+
+
 static int command_parser_version(int fd)
 {
int version = -1;
@@ -51,12 +65,6 @@ static int command_parser_version(int fd)
return -1;
 }
 
-#define HSW_CS_GPR(n) (0x2600 + 8*(n))
-#define HSW_CS_GPR0 HSW_CS_GPR(0)
-#define HSW_CS_GPR1 HSW_CS_GPR(1)
-
-#define MI_LOAD_REGISTER_REG (0x2a << 23)
-#define MI_STORE_REGISTER_MEM (0x24 << 23)
 static void hsw_load_register_reg(void)
 {
uint32_t buf[16] = {
@@ -100,13 +108,13 @@ static void hsw_load_register_reg(void)
reloc[0].offset = 7*sizeof(uint32_t);
reloc[0].target_handle = obj[0].handle;
reloc[0].delta = 0;
-   reloc[0].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
-   reloc[0].write_domain = I915_GEM_DOMAIN_INSTRUCTION;
+   reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
+   reloc[0].write_domain = I915_GEM_DOMAIN_COMMAND;
reloc[1].offset = 13*sizeof(uint32_t);
reloc[1].target_handle = obj[0].handle;
reloc[1].delta = sizeof(uint32_t);
-   reloc[1].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
-   reloc[1].write_domain = I915_GEM_DOMAIN_INSTRUCTION;
+   reloc[1].read_domains = I915_GEM_DOMAIN_COMMAND;
+   reloc[1].write_domain = I915_GEM_DOMAIN_COMMAND;
obj[1].relocs_ptr = (uintptr_t)
obj[1].relocation_count = 2;
 
@@ -152,7 +160,7 @@ static void exec_batch_patched(int fd, uint32_t cmd_bo, 
uint32_t *cmds,
   int size, int patch_offset, uint64_t 
expected_value)
 {
struct drm_i915_gem_execbuffer2 execbuf;
-   struct drm_i915_gem_exec_object2 objs[2];
+   struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_relocation_entry reloc[1];
 
uint32_t target_bo = gem_create(fd, 4096);
@@ -160,42 +168,24 @@ static void exec_batch_patched(int fd, uint32_t cmd_bo, 
uint32_t *cmds,
 
gem_write(fd, cmd_bo, 0, cmds, size);
 
+   memset(obj, 0, sizeof(obj));
+   obj[0].handle = target_bo;
+   obj[1].handle = cmd_bo;
+
+   memset(reloc, 0, sizeof(reloc));
reloc[0].offset = patch_offset;
+   reloc[0].target_handle = obj[0].handle;
reloc[0].delta = 0;
-   reloc[0].target_handle = target_bo;
-   reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
-   reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
-   reloc[0].presumed_offset = 0;
-
-   objs[0].handle = target_bo;
-   objs[0].relocation_count = 0;
-   objs[0].relocs_ptr = 0;
-   objs[0].alignment = 0;
-   objs[0].offset = 0;
-   objs[0].flags = 0;
-   objs[0].rsvd1 = 0;
-   objs[0].rsvd2 = 0;
-
-   objs[1].handle = cmd_bo;
-   objs[1].relocation_count = 1;
-   objs[1].relocs_ptr = (uintptr_t)reloc;
-   objs[1].alignment = 0;
-   objs[1].offset = 0;
-   objs[1].flags = 0;
-   objs[1].rsvd1 = 0;
-   objs[1].rsvd2 = 0;
-
-   execbuf.buffers_ptr = (uintptr_t)objs;
+   reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
+   reloc[0].write_domain = I915_GEM_DOMAIN_COMMAND;
+   obj[1].relocs_ptr = (uintptr_t)reloc;
+   obj[1].relocation_count = 1;
+
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = (uintptr_t)obj;
execbuf.buffer_count = 2;
-   execbuf.batch_start_offset = 0;
execbuf.batch_len = size;
-   execbuf.cliprects_ptr = 0;
-   execbuf.num_cliprects = 0;
-   execbuf.DR1 = 0;
-   execbuf.DR4 = 0;
execbuf.flags = I915_EXEC_RENDER;
-   i915_execbuffer2_set_context_id(execbuf, 0);
-   execbuf.rsvd2 = 0;
 
gem_execbuf(fd, );
gem_sync(fd, cmd_bo);
@@ 

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

[Paulo Zanoni]

Em Seg, 2016-11-14 às 22:26 +0200, Ville Syrjälä escreveu:
> On Fri, Nov 11, 2016 at 06:49:59PM -0200, Paulo Zanoni wrote:
> > 
> > Em Sex, 2016-11-11 às 22:24 +0200, Ville Syrjälä escreveu:
> > > 
> > > On Fri, Nov 11, 2016 at 05:57:28PM -0200, Paulo Zanoni wrote:
> > > > 
> > > > 
> > > > Em Sex, 2016-11-11 às 21:13 +0200, Ville Syrjälä escreveu:
> > > > > 
> > > > > 
> > > > > On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Ville pointed out that intel_fbc_choose_crtc() is
> > > > > > > > iterating
> > > > > > > > over
> > > > > > > > all
> > > > > > > > planes instead of just the primary planes. There are no
> > > > > > > > real
> > > > > > > > consequences of this problem for HSW+, and for the
> > > > > > > > other
> > > > > > > > platforms
> > > > > > > > it
> > > > > > > > just means that in some obscure multi-screen cases
> > > > > > > > we'll
> > > > > > > > keep
> > > > > > > > FBC
> > > > > > > > disabled when we could have enabled it. Still,
> > > > > > > > iterating
> > > > > > > > over
> > > > > > > > all
> > > > > > > > planes doesn't seem to be the best thing to do.
> > > > > > > > 
> > > > > > > > My initial idea was to just add a check for plane->type 
> > > > > > > > and
> > > > > > > > be
> > > > > > > > done,
> > > > > > > > but then I realized that in commits not involving the
> > > > > > > > primary
> > > > > > > > plane
> > > > > > > > we
> > > > > > > > would reset crtc_state->enable_fbc back to false even
> > > > > > > > when
> > > > > > > > FBC
> > > > > > > > is
> > > > > > > > enabled. That also wouldn't result in a bug due to the
> > > > > > > > way
> > > > > > > > the
> > > > > > > > enable_fbc variable is checked, but, still, our code
> > > > > > > > can be
> > > > > > > > better
> > > > > > > > than this.
> > > > > > > > 
> > > > > > > > So I went for the solution that involves tracking
> > > > > > > > enable_fbc in
> > > > > > > > the
> > > > > > > > primary plane state instead of the CRTC state. This
> > > > > > > > way, if
> > > > > > > > a
> > > > > > > > commit
> > > > > > > > doesn't involve the primary plane for the CRTC we won't
> > > > > > > > be
> > > > > > > > resetting
> > > > > > > > enable_fbc back to false, so the variable will always
> > > > > > > > reflect
> > > > > > > > the
> > > > > > > > reality. And this change also makes more sense since
> > > > > > > > FBC is
> > > > > > > > actually
> > > > > > > > tied to the single plane and not the full pipe. As a
> > > > > > > > bonus,
> > > > > > > > we
> > > > > > > > only
> > > > > > > > iterate over the CRTCs instead of iterating over all
> > > > > > > > planes.
> > > > > > > > 
> > > > > > > > Cc: Ville Syrjälä 
> > > > > > > > Reported-by: Ville Syrjälä  > > > > > > > om>
> > > > > > > > Signed-off-by: Paulo Zanoni 
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/i915/intel_drv.h |  4 ++--
> > > > > > > >  drivers/gpu/drm/i915/intel_fbc.c | 36
> > > > > > > > +++-
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > >  2 files changed, 21 insertions(+), 19 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > > > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > > > > > index 003afb8..025cb74 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > > > > > @@ -403,6 +403,8 @@ struct intel_plane_state {
> > > > > > > >     int scaler_id;
> > > > > > > >  
> > > > > > > >     struct drm_intel_sprite_colorkey ckey;
> > > > > > > > +
> > > > > > > > +   bool enable_fbc;
> > > > > > > >  };
> > > > > > > >  
> > > > > > > >  struct intel_initial_plane_config {
> > > > > > > > @@ -648,8 +650,6 @@ struct intel_crtc_state {
> > > > > > > >  
> > > > > > > >     bool ips_enabled;
> > > > > > > >  
> > > > > > > > -   bool enable_fbc;
> > > > > > > > -
> > > > > > > >     bool double_wide;
> > > > > > > >  
> > > > > > > >     bool dp_encoder_is_mst;
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > > > index b095175..fc4ac57 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > > > @@ -1055,16 +1055,17 @@ void
> > > > > > > > intel_fbc_choose_crtc(struct
> > > > > > > > drm_i915_private *dev_priv,
> > > > > > > >        struct drm_atomic_state
> > > > > > > > *state)
> > > > > > > >  {
> > > > > > > >     struct intel_fbc *fbc = 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: rewrite FBC's atomic CRTC-choosing code

[Patchwork]

== Series Details ==

Series: drm/i915: rewrite FBC's atomic CRTC-choosing code
URL   : https://patchwork.freedesktop.org/series/15302/
State : success

== Summary ==

Series 15302v1 drm/i915: rewrite FBC's atomic CRTC-choosing code
https://patchwork.freedesktop.org/api/1.0/series/15302/revisions/1/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

1ff093811f7fdf9b63a9fac336269f2083f1b433 drm-intel-nightly: 
2016y-11m-14d-18h-30m-41s UTC integration manifest
343854e drm/i915: rewrite FBC's atomic CRTC-choosing code

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2988/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [CI 07/10] drm/i915/scheduler: Record all dependencies upon request construction

[Chris Wilson]

The scheduler needs to know the dependencies of each request for the
lifetime of the request, as it may choose to reschedule the requests at
any time and must ensure the dependency tree is not broken. This is in
additional to using the fence to only allow execution after all
dependencies have been completed.

One option was to extend the fence to support the bidirectional
dependency tracking required by the scheduler. However the mismatch in
lifetimes between the submit fence and the request essentially meant
that we had to build a completely separate struct (and we could not
simply reuse the existing waitqueue in the fence for one half of the
dependency tracking). The extra dependency tracking simply did not mesh
well with the fence, and keeping it separate both keeps the fence
implementation simpler and allows us to extend the dependency tracking
into a priority tree (whilst maintaining support for reordering the
tree).

To avoid the additional allocations and list manipulations, the use of
the priotree is disabled when there are no schedulers to use it.

v2: Create a dedicated slab for i915_dependency.
Rename the lists.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_gem.c | 11 +++-
 drivers/gpu/drm/i915/i915_gem_request.c | 91 -
 drivers/gpu/drm/i915/i915_gem_request.h | 33 
 4 files changed, 134 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c4a14de92440..6aad69fe8ccf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1778,6 +1778,7 @@ struct drm_i915_private {
struct kmem_cache *objects;
struct kmem_cache *vmas;
struct kmem_cache *requests;
+   struct kmem_cache *dependencies;
 
const struct intel_device_info info;
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9741f1a19649..faecce3c4d21 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4434,12 +4434,18 @@ i915_gem_load_init(struct drm_device *dev)
if (!dev_priv->requests)
goto err_vmas;
 
+   dev_priv->dependencies = KMEM_CACHE(i915_dependency,
+   SLAB_HWCACHE_ALIGN |
+   SLAB_RECLAIM_ACCOUNT);
+   if (!dev_priv->dependencies)
+   goto err_requests;
+
mutex_lock(_priv->drm.struct_mutex);
INIT_LIST_HEAD(_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
if (err)
-   goto err_requests;
+   goto err_dependencies;
 
INIT_LIST_HEAD(_priv->context_list);
INIT_WORK(_priv->mm.free_work, __i915_gem_free_work);
@@ -4467,6 +4473,8 @@ i915_gem_load_init(struct drm_device *dev)
 
return 0;
 
+err_dependencies:
+   kmem_cache_destroy(dev_priv->dependencies);
 err_requests:
kmem_cache_destroy(dev_priv->requests);
 err_vmas:
@@ -4483,6 +4491,7 @@ void i915_gem_load_cleanup(struct drm_device *dev)
 
WARN_ON(!llist_empty(_priv->mm.free_list));
 
+   kmem_cache_destroy(dev_priv->dependencies);
kmem_cache_destroy(dev_priv->requests);
kmem_cache_destroy(dev_priv->vmas);
kmem_cache_destroy(dev_priv->objects);
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 1118cf48d6f0..78c87d94d205 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -113,6 +113,77 @@ i915_gem_request_remove_from_client(struct 
drm_i915_gem_request *request)
spin_unlock(_priv->mm.lock);
 }
 
+static struct i915_dependency *
+i915_dependency_alloc(struct drm_i915_private *i915)
+{
+   return kmem_cache_alloc(i915->dependencies, GFP_KERNEL);
+}
+
+static void
+i915_dependency_free(struct drm_i915_private *i915,
+struct i915_dependency *dep)
+{
+   kmem_cache_free(i915->dependencies, dep);
+}
+
+static void
+__i915_priotree_add_dependency(struct i915_priotree *pt,
+  struct i915_priotree *signal,
+  struct i915_dependency *dep,
+  unsigned long flags)
+{
+   list_add(>wait_link, >waiters_list);
+   list_add(>signal_link, >signalers_list);
+   dep->signaler = signal;
+   dep->flags = flags;
+}
+
+static int
+i915_priotree_add_dependency(struct drm_i915_private *i915,
+struct i915_priotree *pt,
+struct i915_priotree *signal)
+{
+   struct i915_dependency *dep;
+
+   dep = i915_dependency_alloc(i915);
+   if (!dep)
+   return -ENOMEM;
+
+   

[Intel-gfx] [CI 05/10] drm/i915: Remove engine->execlist_lock

[Chris Wilson]

The execlist_lock is now completely subsumed by the engine->timeline->lock,
and so we can remove the redundant layer of locking.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
 drivers/gpu/drm/i915/i915_gem.c | 8 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c  | 1 -
 drivers/gpu/drm/i915/intel_lrc.c| 7 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
 5 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bce38803f45c..03e3c2afbb06 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3254,11 +3254,11 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
seq_printf(m, "\t\tELSP[1] idle\n");
rcu_read_unlock();
 
-   spin_lock_irq(>execlist_lock);
+   spin_lock_irq(>timeline->lock);
list_for_each_entry(rq, >execlist_queue, 
execlist_link) {
print_request(m, rq, "\t\tQ ");
}
-   spin_unlock_irq(>execlist_lock);
+   spin_unlock_irq(>timeline->lock);
} else if (INTEL_GEN(dev_priv) > 6) {
seq_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
   I915_READ(RING_PP_DIR_BASE(engine)));
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a6ae3efd1d6a..9741f1a19649 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2717,12 +2717,16 @@ static void i915_gem_cleanup_engine(struct 
intel_engine_cs *engine)
 */
 
if (i915.enable_execlists) {
-   spin_lock(>execlist_lock);
+   unsigned long flags;
+
+   spin_lock_irqsave(>timeline->lock, flags);
+
INIT_LIST_HEAD(>execlist_queue);
i915_gem_request_put(engine->execlist_port[0].request);
i915_gem_request_put(engine->execlist_port[1].request);
memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
-   spin_unlock(>execlist_lock);
+
+   spin_unlock_irqrestore(>timeline->lock, flags);
}
 }
 
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 841f8d1e1410..298f0f95dd3f 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -237,7 +237,6 @@ static void intel_engine_init_timeline(struct 
intel_engine_cs *engine)
 void intel_engine_setup_common(struct intel_engine_cs *engine)
 {
INIT_LIST_HEAD(>execlist_queue);
-   spin_lock_init(>execlist_lock);
 
intel_engine_init_timeline(engine);
intel_engine_init_hangcheck(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index dca41834dec1..d1aea7462515 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -471,7 +471,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 */
 
spin_lock_irqsave(>timeline->lock, flags);
-   spin_lock(>execlist_lock);
list_for_each_entry(cursor, >execlist_queue, execlist_link) {
/* Can we combine this request with the current port? It has to
 * be the same context/ringbuffer and not have any exceptions
@@ -524,7 +523,6 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 
i915_gem_request_assign(>request, last);
}
-   spin_unlock(>execlist_lock);
spin_unlock_irqrestore(>timeline->lock, flags);
 
if (submit)
@@ -633,13 +631,14 @@ static void execlists_submit_request(struct 
drm_i915_gem_request *request)
struct intel_engine_cs *engine = request->engine;
unsigned long flags;
 
-   spin_lock_irqsave(>execlist_lock, flags);
+   /* Will be called from irq-context when using foreign fences. */
+   spin_lock_irqsave(>timeline->lock, flags);
 
list_add_tail(>execlist_link, >execlist_queue);
if (execlists_elsp_idle(engine))
tasklet_hi_schedule(>irq_tasklet);
 
-   spin_unlock_irqrestore(>execlist_lock, flags);
+   spin_unlock_irqrestore(>timeline->lock, flags);
 }
 
 int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request 
*request)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d1a728791ad4..e1351870c203 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -335,7 +335,6 @@ struct intel_engine_cs {
 
/* Execlists */
struct tasklet_struct irq_tasklet;
-   spinlock_t execlist_lock; /* used inside tasklet, use spin_lock_bh */

[Intel-gfx] [CI 09/10] drm/i915: Store the execution priority on the context

[Chris Wilson]

In order to support userspace defining different levels of importance to
different contexts, and in particular the preferred order of execution,
store a priority value on each context. By default, the kernel's
context, which is used for idling and other background tasks, is given
minimum priority (i.e. all user contexts will execute before the kernel).

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 drivers/gpu/drm/i915/i915_gem_context.c | 1 +
 drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6aad69fe8ccf..fa8ee8738e7c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -936,6 +936,7 @@ struct i915_gem_context {
/* Unique identifier for this context, used by the hw for tracking */
unsigned int hw_id;
u32 user_handle;
+   int priority; /* greater priorities are serviced first */
 
u32 ggtt_alignment;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 6dd475735f0a..1f94b8d6d83d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -476,6 +476,7 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
 
+   ctx->priority = I915_PRIORITY_MIN; /* lowest priority; idle task */
dev_priv->kernel_context = ctx;
 
DRM_DEBUG_DRIVER("%s context support initialized\n",
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 13574a1e29b1..b9b5253cf3cd 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -867,7 +867,7 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
 * run at the earliest possible convenience.
 */
if (engine->schedule)
-   engine->schedule(request, 0);
+   engine->schedule(request, request->ctx->priority);
 
local_bh_disable();
i915_sw_fence_commit(>submit);
-- 
2.10.2

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

[Intel-gfx] [CI 02/10] drm/i915: Create distinct lockclasses for execution vs user timelines

[Chris Wilson]

In order to simplify the lockdep annotation, as they become more complex
in the future with deferred execution and multiple paths through the
same functions, create a separate lockclass for the user timeline and
the hardware execution timeline.

We should only ever be locking the user timeline and the execution
timeline in parallel so we only need to create two lock classes, rather
than a separate class for every timeline.

v2: Rename the lock classes to be more consistent with other lockdep.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c  |  4 +---
 drivers/gpu/drm/i915/i915_gem_request.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_timeline.c | 33 
 drivers/gpu/drm/i915/i915_gem_timeline.h |  1 +
 4 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ed4465d22dde..a6ae3efd1d6a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4432,9 +4432,7 @@ i915_gem_load_init(struct drm_device *dev)
 
mutex_lock(_priv->drm.struct_mutex);
INIT_LIST_HEAD(_priv->gt.timelines);
-   err = i915_gem_timeline_init(dev_priv,
-_priv->gt.global_timeline,
-"[execution]");
+   err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(_priv->drm.struct_mutex);
if (err)
goto err_requests;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 5050464c5401..f25b537d6e64 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -346,7 +346,7 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
request->ring->vaddr + request->postfix);
engine->submit_request(request);
 
-   spin_lock_nested(>timeline->lock, SINGLE_DEPTH_NESTING);
+   spin_lock(>timeline->lock);
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.c 
b/drivers/gpu/drm/i915/i915_gem_timeline.c
index fc8f13a79f8f..bf8a471b61e6 100644
--- a/drivers/gpu/drm/i915/i915_gem_timeline.c
+++ b/drivers/gpu/drm/i915/i915_gem_timeline.c
@@ -24,9 +24,11 @@
 
 #include "i915_drv.h"
 
-int i915_gem_timeline_init(struct drm_i915_private *i915,
-  struct i915_gem_timeline *timeline,
-  const char *name)
+static int __i915_gem_timeline_init(struct drm_i915_private *i915,
+   struct i915_gem_timeline *timeline,
+   const char *name,
+   struct lock_class_key *lockclass,
+   const char *lockname)
 {
unsigned int i;
u64 fences;
@@ -47,8 +49,11 @@ int i915_gem_timeline_init(struct drm_i915_private *i915,
 
tl->fence_context = fences++;
tl->common = timeline;
-
+#ifdef CONFIG_DEBUG_SPINLOCK
+   __raw_spin_lock_init(>lock.rlock, lockname, lockclass);
+#else
spin_lock_init(>lock);
+#endif
init_request_active(>last_request, NULL);
INIT_LIST_HEAD(>requests);
}
@@ -56,6 +61,26 @@ int i915_gem_timeline_init(struct drm_i915_private *i915,
return 0;
 }
 
+int i915_gem_timeline_init(struct drm_i915_private *i915,
+  struct i915_gem_timeline *timeline,
+  const char *name)
+{
+   static struct lock_class_key class;
+
+   return __i915_gem_timeline_init(i915, timeline, name,
+   , ">lock");
+}
+
+int i915_gem_timeline_init__global(struct drm_i915_private *i915)
+{
+   static struct lock_class_key class;
+
+   return __i915_gem_timeline_init(i915,
+   >gt.global_timeline,
+   "[execution]",
+   , "_timeline->lock");
+}
+
 void i915_gem_timeline_fini(struct i915_gem_timeline *tl)
 {
lockdep_assert_held(>i915->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.h 
b/drivers/gpu/drm/i915/i915_gem_timeline.h
index f2bf7b1d49a1..98d99a62b4ae 100644
--- a/drivers/gpu/drm/i915/i915_gem_timeline.h
+++ b/drivers/gpu/drm/i915/i915_gem_timeline.h
@@ -67,6 +67,7 @@ struct i915_gem_timeline {
 int i915_gem_timeline_init(struct drm_i915_private *i915,
   struct i915_gem_timeline *tl,
   const char *name);
+int i915_gem_timeline_init__global(struct drm_i915_private *i915);
 void i915_gem_timeline_fini(struct i915_gem_timeline *tl);
 
 #endif
-- 
2.10.2

___
Intel-gfx mailing 

[Intel-gfx] [CI 06/10] drm/i915/scheduler: Signal the arrival of a new request

[Chris Wilson]

The start of the scheduler, add a hook into request submission for the
scheduler to see the arrival of new requests and prepare its runqueues.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 
 drivers/gpu/drm/i915/i915_gem_request.c | 13 +
 drivers/gpu/drm/i915/intel_engine_cs.c  |  3 +++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  9 +
 include/uapi/drm/i915_drm.h |  5 +
 5 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a6397f316b30..4f0e56d3b441 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -323,6 +323,10 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
 */
value = i915_gem_mmap_gtt_version();
break;
+   case I915_PARAM_HAS_SCHEDULER:
+   value = dev_priv->engine[RCS] &&
+   dev_priv->engine[RCS]->schedule;
+   break;
case I915_PARAM_MMAP_VERSION:
/* Remember to bump this if the version changes! */
case I915_PARAM_HAS_GEM:
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 952d2aec5244..1118cf48d6f0 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -762,6 +762,19 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
 
i915_gem_mark_busy(engine);
 
+   /* Let the backend know a new request has arrived that may need
+* to adjust the existing execution schedule due to a high priority
+* request - i.e. we may want to preempt the current request in order
+* to run a high priority dependency chain *before* we can execute this
+* request.
+*
+* This is called before the request is ready to run so that we can
+* decide whether to preempt the entire chain so that it is ready to
+* run at the earliest possible convenience.
+*/
+   if (engine->schedule)
+   engine->schedule(request, 0);
+
local_bh_disable();
i915_sw_fence_commit(>submit);
local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 298f0f95dd3f..c9171a058478 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -102,6 +102,9 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->mmio_base = info->mmio_base;
engine->irq_shift = info->irq_shift;
 
+   /* Nothing to do here, execute in order of dependencies */
+   engine->schedule = NULL;
+
dev_priv->engine[id] = engine;
return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index e1351870c203..b9583941eb6b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -267,6 +267,15 @@ struct intel_engine_cs {
 */
void(*submit_request)(struct drm_i915_gem_request *req);
 
+   /* Call when the priority on a request has changed and it and its
+* dependencies may need rescheduling. Note the request itself may
+* not be ready to run!
+*
+* Called under the struct_mutex.
+*/
+   void(*schedule)(struct drm_i915_gem_request *request,
+   int priority);
+
/* Some chipsets are not quite as coherent as advertised and need
 * an expensive kick to force a true read of the up-to-date seqno.
 * However, the up-to-date seqno is not always required and the last
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 03725fe89859..1c12a350eca3 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -389,6 +389,11 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
 
+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
+ * priorities and the driver will attempt to execute batches in priority order.
+ */
+#define I915_PARAM_HAS_SCHEDULER41
+
 typedef struct drm_i915_getparam {
__s32 param;
/*
-- 
2.10.2

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

[Intel-gfx] [CI 01/10] drm/i915: Give each sw_fence its own lockclass

[Chris Wilson]

Localise the static struct lock_class_key to the caller of
i915_sw_fence_init() so that we create a lock_class instance for each
unique sw_fence rather than all sw_fences sharing the same
lock_class. This eliminate some lockdep false positive when using fences
from within fence callbacks.

For the relatively small number of fences currently in use [2], this adds
160 bytes of unused text/code when lockdep is disabled. This seems
quite high, but fully reducing it via ifdeffery is also quite ugly.
Removing the #fence strings saves 72 bytes with just a single #ifdef.

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

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 95f2f12e0917..147420ccf49c 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -116,11 +116,14 @@ static void i915_sw_fence_await(struct i915_sw_fence 
*fence)
WARN_ON(atomic_inc_return(>pending) <= 1);
 }
 
-void i915_sw_fence_init(struct i915_sw_fence *fence, i915_sw_fence_notify_t fn)
+void __i915_sw_fence_init(struct i915_sw_fence *fence,
+ i915_sw_fence_notify_t fn,
+ const char *name,
+ struct lock_class_key *key)
 {
BUG_ON((unsigned long)fn & ~I915_SW_FENCE_MASK);
 
-   init_waitqueue_head(>wait);
+   __init_waitqueue_head(>wait, name, key);
kref_init(>kref);
atomic_set(>pending, 1);
fence->flags = (unsigned long)fn;
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h 
b/drivers/gpu/drm/i915/i915_sw_fence.h
index 707dfc4f0da5..7508d23f823b 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence.h
@@ -40,7 +40,22 @@ typedef int (*i915_sw_fence_notify_t)(struct i915_sw_fence *,
  enum i915_sw_fence_notify state);
 #define __i915_sw_fence_call __aligned(4)
 
-void i915_sw_fence_init(struct i915_sw_fence *fence, i915_sw_fence_notify_t 
fn);
+void __i915_sw_fence_init(struct i915_sw_fence *fence,
+ i915_sw_fence_notify_t fn,
+ const char *name,
+ struct lock_class_key *key);
+#ifdef CONFIG_LOCKDEP
+#define i915_sw_fence_init(fence, fn)  \
+do {   \
+   static struct lock_class_key __key; \
+   \
+   __i915_sw_fence_init((fence), (fn), #fence, &__key);\
+} while (0)
+#else
+#define i915_sw_fence_init(fence, fn)  \
+   __i915_sw_fence_init((fence), (fn), NULL, NULL)
+#endif
+
 void i915_sw_fence_commit(struct i915_sw_fence *fence);
 
 int i915_sw_fence_await_sw_fence(struct i915_sw_fence *fence,
-- 
2.10.2

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

[Intel-gfx] [CI 10/10] drm/i915/scheduler: Boost priorities for flips

[Chris Wilson]

Boost the priority of any rendering required to show the next pageflip
as we want to avoid missing the vblank by being delayed by invisible
workload. We prioritise avoiding jank and jitter in the GUI over
starving background tasks.

v2: Descend dma_fence_array when boosting priorities.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 +++
 drivers/gpu/drm/i915/i915_gem.c  | 65 
 drivers/gpu/drm/i915/intel_display.c |  2 ++
 3 files changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fa8ee8738e7c..4e7148a3ee8b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3093,6 +3093,11 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj,
 unsigned int flags,
 long timeout,
 struct intel_rps_client *rps);
+int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+ unsigned int flags,
+ int priority);
+#define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
+
 int __must_check
 i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
  bool write);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7a43f2a73552..3fb5e66e4d65 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -34,6 +34,7 @@
 #include "intel_drv.h"
 #include "intel_frontbuffer.h"
 #include "intel_mocs.h"
+#include 
 #include 
 #include 
 #include 
@@ -434,6 +435,70 @@ i915_gem_object_wait_reservation(struct reservation_object 
*resv,
return timeout;
 }
 
+static void __fence_set_priority(struct dma_fence *fence, int prio)
+{
+   struct drm_i915_gem_request *rq;
+   struct intel_engine_cs *engine;
+
+   if (!dma_fence_is_i915(fence))
+   return;
+
+   rq = to_request(fence);
+   engine = rq->engine;
+   if (!engine->schedule)
+   return;
+
+   engine->schedule(rq, prio);
+}
+
+static void fence_set_priority(struct dma_fence *fence, int prio)
+{
+   /* Recurse once into a fence-array */
+   if (dma_fence_is_array(fence)) {
+   struct dma_fence_array *array = to_dma_fence_array(fence);
+   int i;
+
+   for (i = 0; i < array->num_fences; i++)
+   __fence_set_priority(array->fences[i], prio);
+   } else {
+   __fence_set_priority(fence, prio);
+   }
+}
+
+int
+i915_gem_object_wait_priority(struct drm_i915_gem_object *obj,
+ unsigned int flags,
+ int prio)
+{
+   struct dma_fence *excl;
+
+   if (flags & I915_WAIT_ALL) {
+   struct dma_fence **shared;
+   unsigned int count, i;
+   int ret;
+
+   ret = reservation_object_get_fences_rcu(obj->resv,
+   , , );
+   if (ret)
+   return ret;
+
+   for (i = 0; i < count; i++) {
+   fence_set_priority(shared[i], prio);
+   dma_fence_put(shared[i]);
+   }
+
+   kfree(shared);
+   } else {
+   excl = reservation_object_get_excl_rcu(obj->resv);
+   }
+
+   if (excl) {
+   fence_set_priority(excl, prio);
+   dma_fence_put(excl);
+   }
+   return 0;
+}
+
 /**
  * Waits for rendering to the object to be completed
  * @obj: i915 gem object
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2711c571add2..cb9377de456e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14790,6 +14790,8 @@ intel_prepare_plane_fb(struct drm_plane *plane,
  GFP_KERNEL);
if (ret < 0)
return ret;
+
+   i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY);
}
 
if (plane->type == DRM_PLANE_TYPE_CURSOR &&
-- 
2.10.2

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

[Intel-gfx] [CI 08/10] drm/i915/scheduler: Execute requests in order of priorities

[Chris Wilson]

Track the priority of each request and use it to determine the order in
which we submit requests to the hardware via execlists.

The priority of the request is determined by the user (eventually via
the context) but may be overridden at any time by the driver. When we set
the priority of the request, we bump the priority of all of its
dependencies to match - so that a high priority drawing operation is not
stuck behind a background task.

When the request is ready to execute (i.e. we have signaled the submit
fence following completion of all its dependencies, including third
party fences), we put the request into a priority sorted rbtree to be
submitted to the hardware. If the request is higher priority than all
pending requests, it will be submitted on the next context-switch
interrupt as soon as the hardware has completed the current request. We
do not currently preempt any current execution to immediately run a very
high priority request, at least not yet.

One more limitation, is that this is first implementation is for
execlists only so currently limited to gen8/gen9.

v2: Replace recursive priority inheritance bumping with an iterative
depth-first search list.
v3: list_next_entry() for walking lists
v4: Explain how the dfs solves the recursion problem with PI.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c|   7 +-
 drivers/gpu/drm/i915/i915_gem.c|   3 +-
 drivers/gpu/drm/i915/i915_gem_request.c|   5 +
 drivers/gpu/drm/i915/i915_gem_request.h|   8 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |   1 +
 drivers/gpu/drm/i915/intel_engine_cs.c |   3 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 151 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h|   3 +-
 8 files changed, 165 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 03e3c2afbb06..1cc971cb6cb1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -631,8 +631,9 @@ static void print_request(struct seq_file *m,
  struct drm_i915_gem_request *rq,
  const char *prefix)
 {
-   seq_printf(m, "%s%x [%x:%x] @ %d: %s\n", prefix,
+   seq_printf(m, "%s%x [%x:%x] prio=%d @ %dms: %s\n", prefix,
   rq->global_seqno, rq->ctx->hw_id, rq->fence.seqno,
+  rq->priotree.priority,
   jiffies_to_msecs(jiffies - rq->emitted_jiffies),
   rq->timeline->common->name);
 }
@@ -3216,6 +3217,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
 
if (i915.enable_execlists) {
u32 ptr, read, write;
+   struct rb_node *rb;
 
seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
   I915_READ(RING_EXECLIST_STATUS_LO(engine)),
@@ -3255,7 +3257,8 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
rcu_read_unlock();
 
spin_lock_irq(>timeline->lock);
-   list_for_each_entry(rq, >execlist_queue, 
execlist_link) {
+   for (rb = engine->execlist_first; rb; rb = rb_next(rb)) 
{
+   rq = rb_entry(rb, typeof(*rq), priotree.node);
print_request(m, rq, "\t\tQ ");
}
spin_unlock_irq(>timeline->lock);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index faecce3c4d21..7a43f2a73552 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2721,10 +2721,11 @@ static void i915_gem_cleanup_engine(struct 
intel_engine_cs *engine)
 
spin_lock_irqsave(>timeline->lock, flags);
 
-   INIT_LIST_HEAD(>execlist_queue);
i915_gem_request_put(engine->execlist_port[0].request);
i915_gem_request_put(engine->execlist_port[1].request);
memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
+   engine->execlist_queue = RB_ROOT;
+   engine->execlist_first = NULL;
 
spin_unlock_irqrestore(>timeline->lock, flags);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 78c87d94d205..13574a1e29b1 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -132,6 +132,7 @@ __i915_priotree_add_dependency(struct i915_priotree *pt,
   struct i915_dependency *dep,
   unsigned long flags)
 {
+   INIT_LIST_HEAD(>dfs_link);
list_add(>wait_link, >waiters_list);
list_add(>signal_link, >signalers_list);
dep->signaler = signal;
@@ -158,6 +159,8 

[Intel-gfx] [CI 04/10] drm/i915: Defer transfer onto execution timeline to actual hw submission

[Chris Wilson]

Defer the transfer from the client's timeline onto the execution
timeline from the point of readiness to the point of actual submission.
For example, in execlists, a request is finally submitted to hardware
when the hardware is ready, and only put onto the hardware queue when
the request is ready. By deferring the transfer, we ensure that the
timeline is maintained in retirement order if we decide to queue the
requests onto the hardware in a different order than fifo.

v2: Rebased onto distinct global/user timeline lock classes.
v3: Play with the position of the spin_lock().
v4: Nesting finally resolved with distinct sw_fence lock classes.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c| 38 --
 drivers/gpu/drm/i915/i915_gem_request.h|  3 +++
 drivers/gpu/drm/i915/i915_guc_submission.c | 14 ++-
 drivers/gpu/drm/i915/intel_lrc.c   | 23 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.c|  2 ++
 5 files changed, 57 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index d0f6b9f82636..952d2aec5244 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -306,25 +306,16 @@ static u32 timeline_get_seqno(struct i915_gem_timeline 
*tl)
return atomic_inc_return(>next_seqno);
 }
 
-static int __i915_sw_fence_call
-submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+void __i915_gem_request_submit(struct drm_i915_gem_request *request)
 {
-   struct drm_i915_gem_request *request =
-   container_of(fence, typeof(*request), submit);
struct intel_engine_cs *engine = request->engine;
struct intel_timeline *timeline;
-   unsigned long flags;
u32 seqno;
 
-   if (state != FENCE_COMPLETE)
-   return NOTIFY_DONE;
-
/* Transfer from per-context onto the global per-engine timeline */
timeline = engine->timeline;
GEM_BUG_ON(timeline == request->timeline);
-
-   /* Will be called from irq-context when using foreign DMA fences */
-   spin_lock_irqsave(>lock, flags);
+   assert_spin_locked(>lock);
 
seqno = timeline_get_seqno(timeline->common);
GEM_BUG_ON(!seqno);
@@ -344,15 +335,36 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
GEM_BUG_ON(!request->global_seqno);
engine->emit_breadcrumb(request,
request->ring->vaddr + request->postfix);
-   engine->submit_request(request);
 
spin_lock(>timeline->lock);
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);
 
i915_sw_fence_commit(>execute);
+}
+
+void i915_gem_request_submit(struct drm_i915_gem_request *request)
+{
+   struct intel_engine_cs *engine = request->engine;
+   unsigned long flags;
 
-   spin_unlock_irqrestore(>lock, flags);
+   /* Will be called from irq-context when using foreign fences. */
+   spin_lock_irqsave(>timeline->lock, flags);
+
+   __i915_gem_request_submit(request);
+
+   spin_unlock_irqrestore(>timeline->lock, flags);
+}
+
+static int __i915_sw_fence_call
+submit_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+{
+   if (state == FENCE_COMPLETE) {
+   struct drm_i915_gem_request *request =
+   container_of(fence, typeof(*request), submit);
+
+   request->engine->submit_request(request);
+   }
 
return NOTIFY_DONE;
 }
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 4976039189ea..4d2784633d9f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -232,6 +232,9 @@ void __i915_add_request(struct drm_i915_gem_request *req, 
bool flush_caches);
 #define i915_add_request_no_flush(req) \
__i915_add_request(req, false)
 
+void __i915_gem_request_submit(struct drm_i915_gem_request *request);
+void i915_gem_request_submit(struct drm_i915_gem_request *request);
+
 struct intel_rps_client;
 #define NO_WAITBOOST ERR_PTR(-1)
 #define IS_RPS_CLIENT(p) (!IS_ERR(p))
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 666dab7a675a..942f5000d372 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -629,11 +629,23 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
 static void i915_guc_submit(struct drm_i915_gem_request *rq)
 {
struct drm_i915_private *dev_priv = rq->i915;
-   unsigned int engine_id = rq->engine->id;
+   struct intel_engine_cs *engine = rq->engine;
+   unsigned int engine_id = engine->id;
struct intel_guc *guc = >i915->guc;
struct 

[Intel-gfx] [CI 03/10] drm/i915: Split request submit/execute phase into two

[Chris Wilson]

In order to support deferred scheduling, we need to differentiate
between when the request is ready to run (i.e. the submit fence is
signaled) and when the request is actually run (a new execute fence).
This is typically split between the request itself wanting to wait upon
others (for which we use the submit fence) and the CPU wanting to wait
upon the request, for which we use the execute fence to be sure the
hardware is ready to signal completion.

Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 33 -
 drivers/gpu/drm/i915/i915_gem_request.h | 15 +++
 2 files changed, 39 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index f25b537d6e64..d0f6b9f82636 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -350,11 +350,19 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
list_move_tail(>link, >requests);
spin_unlock(>timeline->lock);
 
+   i915_sw_fence_commit(>execute);
+
spin_unlock_irqrestore(>lock, flags);
 
return NOTIFY_DONE;
 }
 
+static int __i915_sw_fence_call
+execute_notify(struct i915_sw_fence *fence, enum i915_sw_fence_notify state)
+{
+   return NOTIFY_DONE;
+}
+
 /**
  * i915_gem_request_alloc - allocate a request structure
  *
@@ -440,6 +448,12 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
   __timeline_get_seqno(req->timeline->common));
 
i915_sw_fence_init(>submit, submit_notify);
+   i915_sw_fence_init(>execute, execute_notify);
+   /* Ensure that the execute fence completes after the submit fence -
+* as we complete the execute fence from within the submit fence
+* callback, its completion would otherwise be visible first.
+*/
+   i915_sw_fence_await_sw_fence(>execute, >submit, >execq);
 
INIT_LIST_HEAD(>active_list);
req->i915 = dev_priv;
@@ -816,9 +830,9 @@ bool __i915_spin_request(const struct drm_i915_gem_request 
*req,
 }
 
 static long
-__i915_request_wait_for_submit(struct drm_i915_gem_request *request,
-  unsigned int flags,
-  long timeout)
+__i915_request_wait_for_execute(struct drm_i915_gem_request *request,
+   unsigned int flags,
+   long timeout)
 {
const int state = flags & I915_WAIT_INTERRUPTIBLE ?
TASK_INTERRUPTIBLE : TASK_UNINTERRUPTIBLE;
@@ -830,9 +844,9 @@ __i915_request_wait_for_submit(struct drm_i915_gem_request 
*request,
add_wait_queue(q, );
 
do {
-   prepare_to_wait(>submit.wait, , state);
+   prepare_to_wait(>execute.wait, , state);
 
-   if (i915_sw_fence_done(>submit))
+   if (i915_sw_fence_done(>execute))
break;
 
if (flags & I915_WAIT_LOCKED &&
@@ -850,7 +864,7 @@ __i915_request_wait_for_submit(struct drm_i915_gem_request 
*request,
 
timeout = io_schedule_timeout(timeout);
} while (timeout);
-   finish_wait(>submit.wait, );
+   finish_wait(>execute.wait, );
 
if (flags & I915_WAIT_LOCKED)
remove_wait_queue(q, );
@@ -902,13 +916,14 @@ long i915_wait_request(struct drm_i915_gem_request *req,
 
trace_i915_gem_request_wait_begin(req);
 
-   if (!i915_sw_fence_done(>submit)) {
-   timeout = __i915_request_wait_for_submit(req, flags, timeout);
+   if (!i915_sw_fence_done(>execute)) {
+   timeout = __i915_request_wait_for_execute(req, flags, timeout);
if (timeout < 0)
goto complete;
 
-   GEM_BUG_ON(!i915_sw_fence_done(>submit));
+   GEM_BUG_ON(!i915_sw_fence_done(>execute));
}
+   GEM_BUG_ON(!i915_sw_fence_done(>submit));
GEM_BUG_ON(!req->global_seqno);
 
/* Optimistic short spin before touching IRQs */
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index a56559e3b034..4976039189ea 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -87,8 +87,23 @@ struct drm_i915_gem_request {
struct intel_timeline *timeline;
struct intel_signal_node signaling;
 
+   /* Fences for the various phases in the request's lifetime.
+*
+* The submit fence is used to await upon all of the request's
+* dependencies. When it is signaled, the request is ready to run.
+* It is used by the driver to then queue the request for execution.
+*
+* The execute fence is used to signal when the request has been

Re: [Intel-gfx] [PATCH 6/7] drm/i915/fbc: move from crtc_state->enable_fbc to plane_state->enable_fbc

[Ville Syrjälä]

On Fri, Nov 11, 2016 at 06:49:59PM -0200, Paulo Zanoni wrote:
> Em Sex, 2016-11-11 às 22:24 +0200, Ville Syrjälä escreveu:
> > On Fri, Nov 11, 2016 at 05:57:28PM -0200, Paulo Zanoni wrote:
> > > 
> > > Em Sex, 2016-11-11 às 21:13 +0200, Ville Syrjälä escreveu:
> > > > 
> > > > On Fri, Nov 11, 2016 at 05:01:54PM -0200, Paulo Zanoni wrote:
> > > > > 
> > > > > 
> > > > > Em Sex, 2016-11-11 às 20:51 +0200, Ville Syrjälä escreveu:
> > > > > > 
> > > > > > 
> > > > > > On Fri, Nov 11, 2016 at 02:57:40PM -0200, Paulo Zanoni wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > Ville pointed out that intel_fbc_choose_crtc() is iterating
> > > > > > > over
> > > > > > > all
> > > > > > > planes instead of just the primary planes. There are no
> > > > > > > real
> > > > > > > consequences of this problem for HSW+, and for the other
> > > > > > > platforms
> > > > > > > it
> > > > > > > just means that in some obscure multi-screen cases we'll
> > > > > > > keep
> > > > > > > FBC
> > > > > > > disabled when we could have enabled it. Still, iterating
> > > > > > > over
> > > > > > > all
> > > > > > > planes doesn't seem to be the best thing to do.
> > > > > > > 
> > > > > > > My initial idea was to just add a check for plane->type and
> > > > > > > be
> > > > > > > done,
> > > > > > > but then I realized that in commits not involving the
> > > > > > > primary
> > > > > > > plane
> > > > > > > we
> > > > > > > would reset crtc_state->enable_fbc back to false even when
> > > > > > > FBC
> > > > > > > is
> > > > > > > enabled. That also wouldn't result in a bug due to the way
> > > > > > > the
> > > > > > > enable_fbc variable is checked, but, still, our code can be
> > > > > > > better
> > > > > > > than this.
> > > > > > > 
> > > > > > > So I went for the solution that involves tracking
> > > > > > > enable_fbc in
> > > > > > > the
> > > > > > > primary plane state instead of the CRTC state. This way, if
> > > > > > > a
> > > > > > > commit
> > > > > > > doesn't involve the primary plane for the CRTC we won't be
> > > > > > > resetting
> > > > > > > enable_fbc back to false, so the variable will always
> > > > > > > reflect
> > > > > > > the
> > > > > > > reality. And this change also makes more sense since FBC is
> > > > > > > actually
> > > > > > > tied to the single plane and not the full pipe. As a bonus,
> > > > > > > we
> > > > > > > only
> > > > > > > iterate over the CRTCs instead of iterating over all
> > > > > > > planes.
> > > > > > > 
> > > > > > > Cc: Ville Syrjälä 
> > > > > > > Reported-by: Ville Syrjälä 
> > > > > > > Signed-off-by: Paulo Zanoni 
> > > > > > > ---
> > > > > > >  drivers/gpu/drm/i915/intel_drv.h |  4 ++--
> > > > > > >  drivers/gpu/drm/i915/intel_fbc.c | 36 +++-
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > >  2 files changed, 21 insertions(+), 19 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > > > > index 003afb8..025cb74 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > > > > @@ -403,6 +403,8 @@ struct intel_plane_state {
> > > > > > >   int scaler_id;
> > > > > > >  
> > > > > > >   struct drm_intel_sprite_colorkey ckey;
> > > > > > > +
> > > > > > > + bool enable_fbc;
> > > > > > >  };
> > > > > > >  
> > > > > > >  struct intel_initial_plane_config {
> > > > > > > @@ -648,8 +650,6 @@ struct intel_crtc_state {
> > > > > > >  
> > > > > > >   bool ips_enabled;
> > > > > > >  
> > > > > > > - bool enable_fbc;
> > > > > > > -
> > > > > > >   bool double_wide;
> > > > > > >  
> > > > > > >   bool dp_encoder_is_mst;
> > > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > > b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > > index b095175..fc4ac57 100644
> > > > > > > --- a/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > > +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > > > > > > @@ -1055,16 +1055,17 @@ void intel_fbc_choose_crtc(struct
> > > > > > > drm_i915_private *dev_priv,
> > > > > > >      struct drm_atomic_state *state)
> > > > > > >  {
> > > > > > >   struct intel_fbc *fbc = _priv->fbc;
> > > > > > > - struct drm_plane *plane;
> > > > > > > - struct drm_plane_state *plane_state;
> > > > > > > + struct drm_crtc *crtc;
> > > > > > > + struct drm_crtc_state *crtc_state;
> > > > > > >   bool crtc_chosen = false;
> > > > > > >   int i;
> > > > > > >  
> > > > > > >   mutex_lock(>lock);
> > > > > > >  
> > > > > > > - /* Does this atomic commit involve the CRTC
> > > > > > > currently
> > > > > > > tied
> > > > > > > to FBC? */
> > > > > > > + /* Does this atomic commit involve the plane
> > > > > > > currently
> > > > > > > tied to FBC? */
> > > > > > >   if (fbc->crtc &&
> > > > > > > - !drm_atomic_get_existing_crtc_state(state,
> > > > > > > 
> > > > > 

[Intel-gfx] [PATCH] drm/i915: rewrite FBC's atomic CRTC-choosing code

[Paulo Zanoni]

Ville pointed out that intel_fbc_choose_crtc() is iterating over all
planes instead of just the primary planes. There are no real
consequences of this problem for HSW+, and for the other platforms it
just means that in some obscure multi-screen cases we'll keep FBC
disabled when we could have enabled it. Still, iterating over all
planes doesn't seem to be the best thing to do.

My initial idea was to just add a check for plane->type and be done,
but then I realized that in commits not involving the primary plane we
would reset crtc_state->enable_fbc back to false even when FBC is
enabled. That also wouldn't result in a bug due to the way the
enable_fbc variable is checked, but, still, our code can be better
than this.

So I went for the solution that involves tracking enable_fbc in the
primary plane state instead of the CRTC state. This way, if a commit
doesn't involve the primary plane for the CRTC we won't be resetting
enable_fbc back to false, so the variable will always reflect the
reality. And this change also makes more sense since FBC is actually
tied to the single plane and not the full pipe. As a bonus, we only
iterate over the CRTCs instead of iterating over all planes.

v2:

But Ville pointed that this only works properly if we have a single
commit with multiple CRTCs. If we have multiple parallel commits, each
with its own CRTC, we'll end with enable_fbc set to true in more than
one plane.

So the solution was to rename enable_fbc to can_enable_fbc. If we just
did the rename as the patch was, we'd end up with a single plane with
can_enable_fbc on commits involving multiple CRTCs: we'd choose the
best one, but we'd still end up with a variable that doesn't 100%
reflect reality.

So in the end I adopted Ville's suggestion of the fbc_score variable.
And then, instead of checking the score at intel_fbc_choose_crtc()
it should be possible to check for the score at intel_fbc_enable().
This allows us to simplify intel_fbc_choose_crtc() to the point where
it only needs to look at the given plane in order to assign its score
instead of looking at every primary plane on the same commit.

We still only set scores of 0 and 1 and we don't really do the
score-checking loop.

Cc: Ville Syrjälä 
Reported-by: Ville Syrjälä 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c |  3 +-
 drivers/gpu/drm/i915/intel_drv.h |  8 ++--
 drivers/gpu/drm/i915/intel_fbc.c | 85 
 3 files changed, 35 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 072a0b1..618ddc8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14133,7 +14133,6 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
return ret;
 
-   intel_fbc_choose_crtc(dev_priv, state);
return calc_watermark_data(state);
 }
 
@@ -14897,6 +14896,8 @@ intel_check_primary_plane(struct drm_plane *plane,
return ret;
}
 
+   intel_fbc_check_plane(state);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 003afb8..f2d21d9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -402,6 +402,9 @@ struct intel_plane_state {
 */
int scaler_id;
 
+   /* 0: not suitable for FBC, 1+: suitable for FBC, more is better. */
+   unsigned int fbc_score;
+
struct drm_intel_sprite_colorkey ckey;
 };
 
@@ -648,8 +651,6 @@ struct intel_crtc_state {
 
bool ips_enabled;
 
-   bool enable_fbc;
-
bool double_wide;
 
bool dp_encoder_is_mst;
@@ -1500,8 +1501,7 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 #endif
 
 /* intel_fbc.c */
-void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv,
-  struct drm_atomic_state *state);
+void intel_fbc_check_plane(struct intel_plane_state *plane_state);
 bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
 void intel_fbc_pre_update(struct intel_crtc *crtc,
  struct intel_crtc_state *crtc_state,
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 62f215b..54fabe3 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1040,68 +1040,32 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
 }
 
 /**
- * intel_fbc_choose_crtc - select a CRTC to enable FBC on
- * @dev_priv: i915 device instance
- * @state: the atomic state structure
+ * intel_fbc_check_plane - check plane for FBC suitability
+ * @plane_state: the plane state
  *
- * This function looks at the proposed state for CRTCs and planes, then chooses
- * which pipe is going to have FBC by setting intel_crtc_state->enable_fbc to
- * true.
+ * This 

Re: [Intel-gfx] [PATCH 0/7] FBC atomic cleanups

[Paulo Zanoni]

Em Sex, 2016-11-11 às 14:57 -0200, Paulo Zanoni escreveu:
> Ville pointed out two ugly defects in the FBC code, and while trying
> to fix them I spotted a few extra things. No real-world bugs fixed
> here, but IMHO the code is much easier to read now.

I merged patches 1-5 and 7, and will resend patch 6 as a separate
series. Thanks for the quick reviews!

> 
> Paulo Zanoni (7):
>   drm/i915/fbc: move the intel_fbc_can_choose() call out of the loop
>   drm/i915/fbc: replace a loop with
> drm_atomic_get_existing_crtc_state()
>   drm/i915/fbc: extract intel_fbc_can_enable()
>   drm/i915/fbc: inline intel_fbc_can_choose()
>   drm/i915/fbc: use drm_atomic_get_existing_crtc_state when
> appropriate
>   drm/i915/fbc: move from crtc_state->enable_fbc to
> plane_state->enable_fbc
>   drm/i915/fbc: convert intel_fbc.c to use INTEL_GEN()
> 
>  drivers/gpu/drm/i915/intel_drv.h |  4 +-
>  drivers/gpu/drm/i915/intel_fbc.c | 97 ++--
> 
>  2 files changed, 46 insertions(+), 55 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gen9: fix the WM memory bandwidth WA for Y tiling cases

[Paulo Zanoni]

Em Ter, 2016-11-08 às 17:38 -0800, Matt Roper escreveu:
> On Tue, Nov 08, 2016 at 06:22:11PM -0200, Paulo Zanoni wrote:
> > 
> > The previous spec version said "double Ytile planes minimum lines",
> > and I interpreted this as referring to what the spec calls "Y tile
> > minimum", but in fact it was referring to what the spec calls
> > "Minimum
> > Scanlines for Y tile". I noticed that Mahesh Kumar had a different
> > interpretation, so I sent and email to the spec authors and got
> > clarification on the correct meaning. Also, BSpec was updated and
> > should be clear now.
> > 
> > Fixes: ee3d532fcb64 ("drm/i915/gen9: unconditionally apply the
> > memory bandwidth WA")
> > Cc: sta...@vger.kernel.org
> > Cc: Mahesh Kumar 
> > Signed-off-by: Paulo Zanoni 
> 
> This seems to match my reading of the spec update from Nov 4th, so:
> 
> Reviewed-by: Matt Roper 

Patch merged today. Thanks for the review!

> 
> 
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index cc9e0c0..653525f 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3624,6 +3624,9 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >     y_min_scanlines = 4;
> >     }
> >  
> > +   if (apply_memory_bw_wa)
> > +   y_min_scanlines *= 2;
> > +
> >     plane_bytes_per_line = width * cpp;
> >     if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> >     fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > @@ -3644,8 +3647,6 @@ static int skl_compute_plane_wm(const struct
> > drm_i915_private *dev_priv,
> >      plane_blocks_per_line);
> >  
> >     y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
> > -   if (apply_memory_bw_wa)
> > -   y_tile_minimum *= 2;
> >  
> >     if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> >     fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

[Vivi, Rodrigo]

On Fri, 2016-11-11 at 15:09 +0200, Imre Deak wrote:
> On to, 2016-11-10 at 17:03 -0800, Rodrigo Vivi wrote:
> > According to Bspec we need to
> > "Poll for PORT_REF_DW3_A grc_done == 1b"
> > only on ports B and C initialization sequence when
> > copying rcomp from port A.
> > 
> > So let's follow the spec and only poll for that case
> > and not on every port A initialization.
> > 
> > Cc: Imre Deak 
> > Cc: Ander Conselvan de Oliveira 
> > Signed-off-by: Rodrigo Vivi 
> 
> The current code isn't against the spec, we just wait for the
> calibration to complete earlier. This way we also wait in case only
> port A is enabled which is imo safer to do before a subsequent modeset
> on port A. But yes, the spec suggests the HW will handle the wait for
> this - only port A - case internally, so we can move the wait later to
> reduce somewhat the init time:
> 
> Reviewed-by: Imre Deak 

Ops, actually I noticed later that I need to remove the warning block
with return false from is_phy_enabled if grc isn't done. otherwise it
will force a reprograming without this line there.

So, do you believe it is worth to do a v2 removing that block or better
to just ignore this patch?

> 
> > ---
> >  drivers/gpu/drm/i915/intel_dpio_phy.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
> > b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > index 7a8e82d..277b1aa 100644
> > --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > @@ -367,6 +367,9 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
> > *dev_priv,
> >  
> > if (phy_info->rcomp_phy != -1) {
> > uint32_t grc_code;
> > +
> > +   bxt_phy_wait_grc_done(dev_priv, phy_info->rcomp_phy);
> > +
> > /*
> >  * PHY0 isn't connected to an RCOMP resistor so copy over
> >  * the corresponding calibrated value from PHY1, and disable
> > @@ -387,10 +390,6 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
> > *dev_priv,
> > val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
> > val |= COMMON_RESET_DIS;
> > I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
> > -
> > -   if (phy_info->rcomp_phy == -1)
> > -   bxt_phy_wait_grc_done(dev_priv, phy);
> > -
> >  }
> >  
> >  void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum dpio_phy 
> > phy)

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

Re: [Intel-gfx] [PATCH igt v3 06/11] igt/gem_exec_parse: make basic-rejected version agnostic

[Matthew Auld]

On 9 November 2016 at 16:15, Robert Bragg  wrote:
> This adapts the basic-rejected test to focus on invalid commands that
> will result in an EINVAL errno being returned to userspace even with the
> upcoming version 8 parser change to stop reporting access violations as
> EINVAL errors.
>
> Signed-off-by: Robert Bragg 
> ---
>  tests/gem_exec_parse.c | 28 +---
>  1 file changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
> index 368f30b..63f4efe 100644
> --- a/tests/gem_exec_parse.c
> +++ b/tests/gem_exec_parse.c
> @@ -386,33 +386,39 @@ igt_main
> }
>
> igt_subtest("basic-rejected") {
> -   uint32_t arb_on_off[] = {
> -   MI_ARB_ON_OFF,
> +   uint32_t invalid_cmd[] = {
> +   (0x7<<29), /* Reserved command type,
> + across all engines */
Maybe make this more clear with something like:

   (INSTR_INVALID_CLIENT << INSTR_CLIENT_SHIFT)

Anyway:
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/9] drm/i915: Remove some duplicated plane swapping logic

[Ville Syrjälä]

On Tue, Nov 08, 2016 at 03:23:14PM +, Chris Wilson wrote:
> On Tue, Nov 08, 2016 at 04:47:11PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > On pre-gen4 we connect plane A to pipe B and vice versa to get an FBC
> > capable plane feeding the LVDS port by default. We have the logic for
> > the plane swapping duplicated in many places. Let's remove a bit of the
> > duplication by having the crtc look up the thing from the primary plane.
> 
> And intel_crtc->plane is just a left over to be removed when we go full
> atomic.
>  
> > Signed-off-by: Ville Syrjälä 
> Reviewed-by: Chris Wilson 

Pushed this one to dinq. Thanks for the review.

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A few DP stragglers

[Ville Syrjälä]

On Mon, Nov 14, 2016 at 08:22:42PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 06:16:49PM -, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: drm/i915: A few DP stragglers
> > URL   : https://patchwork.freedesktop.org/series/15299/
> > State : warning
> > 
> > == Summary ==
> > 
> > Series 15299v1 drm/i915: A few DP stragglers
> > https://patchwork.freedesktop.org/api/1.0/series/15299/revisions/1/mbox/
> > 
> > Test kms_pipe_crc_basic:
> > Subgroup nonblocking-crc-pipe-b:
> > pass   -> DMESG-WARN (fi-snb-2520m)
> 
> [  468.452200] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, 
> remainder is 44
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=98625

And series pushed to dinq. Thanks for the review.

> 
> > 
> > fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
> > fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
> > fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
> > fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
> > fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
> > fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
> > fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
> > fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
> > fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> > fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> > fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> > fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
> > fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
> > fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
> > fi-snb-2520m total:244  pass:211  dwarn:1   dfail:0   fail:0   skip:32 
> > fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
> > 
> > 8670f0f0d91190e0d090ee910c73ed83c37cfef5 drm-intel-nightly: 
> > 2016y-11m-14d-16h-10m-52s UTC integration manifest
> > 1c9d66a drm/i915: Simplify DP port limited color range bit platform checks
> > 73f4bd0 drm/i915: Kill dp_encoder_is_mst
> > 
> > == Logs ==
> > 
> > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2987/
> 
> -- 
> Ville Syrjälä
> Intel OTC

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A few DP stragglers

[Ville Syrjälä]

On Mon, Nov 14, 2016 at 06:16:49PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: A few DP stragglers
> URL   : https://patchwork.freedesktop.org/series/15299/
> State : warning
> 
> == Summary ==
> 
> Series 15299v1 drm/i915: A few DP stragglers
> https://patchwork.freedesktop.org/api/1.0/series/15299/revisions/1/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-b:
> pass   -> DMESG-WARN (fi-snb-2520m)

[  468.452200] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, 
remainder is 44

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

> 
> fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
> fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
> fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
> fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
> fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
> fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
> fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
> fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
> fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
> fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
> fi-snb-2520m total:244  pass:211  dwarn:1   dfail:0   fail:0   skip:32 
> fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
> 
> 8670f0f0d91190e0d090ee910c73ed83c37cfef5 drm-intel-nightly: 
> 2016y-11m-14d-16h-10m-52s UTC integration manifest
> 1c9d66a drm/i915: Simplify DP port limited color range bit platform checks
> 73f4bd0 drm/i915: Kill dp_encoder_is_mst
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2987/

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Per-plane rotation leftovers

[Ville Syrjälä]

On Mon, Nov 14, 2016 at 05:47:19PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Per-plane rotation leftovers
> URL   : https://patchwork.freedesktop.org/series/15290/
> State : success

And series pushed to dinq. Thanks for the reviews.

> 
> == Summary ==
> 
> Series 15290v1 drm/i915: Per-plane rotation leftovers
> https://patchwork.freedesktop.org/api/1.0/series/15290/revisions/1/mbox/
> 
> 
> fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
> fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
> fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
> fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
> fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
> fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
> fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
> fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
> fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
> fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
> fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
> fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
> fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
> fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 
> 
> 8670f0f0d91190e0d090ee910c73ed83c37cfef5 drm-intel-nightly: 
> 2016y-11m-14d-16h-10m-52s UTC integration manifest
> 86c7280 drm/i915: Add horizontal mirroring support for CHV pipe B planes
> c2f2b21 drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup
> 00f1032 drm/i915: Use & instead if == to check for rotations
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2986/

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: A few DP stragglers

[Patchwork]

== Series Details ==

Series: drm/i915: A few DP stragglers
URL   : https://patchwork.freedesktop.org/series/15299/
State : warning

== Summary ==

Series 15299v1 drm/i915: A few DP stragglers
https://patchwork.freedesktop.org/api/1.0/series/15299/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
pass   -> DMESG-WARN (fi-snb-2520m)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-snb-2520m total:244  pass:211  dwarn:1   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

8670f0f0d91190e0d090ee910c73ed83c37cfef5 drm-intel-nightly: 
2016y-11m-14d-16h-10m-52s UTC integration manifest
1c9d66a drm/i915: Simplify DP port limited color range bit platform checks
73f4bd0 drm/i915: Kill dp_encoder_is_mst

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2987/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Add a per-pipe plane identifier enum (rev4)

[Ville Syrjälä]

On Wed, Nov 09, 2016 at 04:24:58PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Add a per-pipe plane identifier enum (rev4)
> URL   : https://patchwork.freedesktop.org/series/14978/
> State : warning
> 
> == Summary ==
> 
> Series 14978v4 drm/i915: Add a per-pipe plane identifier enum
> https://patchwork.freedesktop.org/api/1.0/series/14978/revisions/4/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (fi-skl-6770hq)

[   26.882144] [drm:drm_dp_dual_mode_detect] DP dual mode HDMI ID: DP-HDMI 
ADAPTOR\004 (err 0)
[   26.882800] [drm:drm_dp_dual_mode_detect] DP dual mode adaptor ID: 44 (err 0)
[   26.882823] [drm:lspcon_init [i915]] No LSPCON detected, found type 1 HDMI
[   26.882862] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[   26.882884] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B

The bug seems to contain multiple lspcon issues potentially, so not sure
if we're tracking it all there or what:
https://bugs.freedesktop.org/show_bug.cgi?id=98353

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

[  325.952021] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:50:VGA-1]
[  325.952051] [drm:intel_crt_detect [i915]] [CONNECTOR:50:VGA-1] force=1
[  325.952087] [drm:intel_crt_detect [i915]] ironlake hotplug adpa=0x40f4, 
result 0
[  325.952112] [drm:intel_crt_detect [i915]] CRT not detected via hotplug
[  325.952392] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus vga] NAK for addr: 
0050 w(1)
[  325.952421] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus vga] NAK on first 
message, retry
[  325.953097] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus vga] NAK for addr: 
0050 w(1)
[  325.953104] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter 
i915 gmbus vga
[  325.953132] [drm:intel_crt_get_edid [i915]] CRT GMBUS EDID read failed, 
retry using GPIO bit-banging
[  325.953159] [drm:intel_gmbus_force_bit [i915]] enabling bit-banging on i915 
gmbus vga. force bit now 1
[  325.954322] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter 
i915 gmbus vga
[  325.954351] [drm:intel_gmbus_force_bit [i915]] disabling bit-banging on i915 
gmbus vga. force bit now 0
[  325.954378] [drm:intel_crt_detect_ddc [i915]] CRT not detected via DDC:0x50 
[no valid EDID found]
[  325.954383] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:50:VGA-1] disconnected
[  325.954746] [drm:status_store] [CONNECTOR:50:VGA-1] force updated from 0 to 
2 or reprobing
[  325.954752] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:50:VGA-1]
[  325.954758] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:50:VGA-1] status updated from disconnected to connected
[  325.955068] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus vga] NAK for addr: 
0050 w(1)
[  325.955098] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus vga] NAK on first 
message, retry
[  325.955334] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus vga] NAK for addr: 
0050 w(1)
[  325.955341] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter 
i915 gmbus vga
[  325.955368] [drm:intel_crt_get_edid [i915]] CRT GMBUS EDID read failed, 
retry using GPIO bit-banging
[  325.955394] [drm:intel_gmbus_force_bit [i915]] enabling bit-banging on i915 
gmbus vga. force bit now 1
[  325.956456] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent adapter 
i915 gmbus vga
[  325.956484] [drm:intel_gmbus_force_bit [i915]] disabling bit-banging on i915 
gmbus vga. force bit now 0
[  325.956563] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:50:VGA-1] probed modes :
[  325.956584] [drm:drm_mode_debug_printmodeline] Modeline 74:"1024x768" 60 
65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[  325.956594] [drm:drm_mode_debug_printmodeline] Modeline 72:"800x600" 60 
4 800 840 968 1056 600 601 605 628 0x40 0x5
[  325.956601] [drm:drm_mode_debug_printmodeline] Modeline 71:"800x600" 56 
36000 800 824 896 1024 600 601 603 625 0x40 0x5
[  325.956613] [drm:drm_mode_debug_printmodeline] Modeline 73:"848x480" 60 
33750 848 864 976 1088 480 486 494 517 0x40 0x5
[  325.956620] [drm:drm_mode_debug_printmodeline] Modeline 70:"640x480" 60 
25175 640 656 752 800 480 490 492 525 0x40 0xa
...
[  339.524802] [drm:status_store] [CONNECTOR:50:VGA-1] force updated from 2 to 
0 or reprobing
[  339.524808] [drm:drm_helper_probe_single_connector_modes] 
[CONNECTOR:50:VGA-1]
[  339.524845] [drm:intel_crt_detect [i915]] [CONNECTOR:50:VGA-1] force=1
[  339.524880] [drm:intel_crt_detect [i915]] ironlake hotplug adpa=0x43f4, 
result 1
[  339.524904] [drm:intel_crt_detect [i915]] CRT detected via hotplug
[  339.525639] 

Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

[Manasi Navare]

Yes driver can chose to have the pre train for kernel hiding unsupported mode, 
that is completely still possible for the amd driver and it would never use the 
link_status connector property and no interaction with userspace.
Could you please give your ACKs for the patches if you are okay with this 
porposal?

Regards
Manasi



On Mon, Nov 14, 2016 at 02:45:55PM +, Cheng, Tony wrote:
> I see.  As long as amd can still just have kernel hiding unsupported mode by 
> doing a pre-train I am okay with the proposal.  Just to caution you the link 
> training fallback we implemented on windows in old dal architecture is very 
> painful to get right.  Windows 7, 8.1 and 10 all behave differently.  Not all 
> apps handles mode change failure gracefully and worse case we get stuck in 
> infinite mode set.  This is why for future generations asic on windows we are 
> also going to just hide unsupported mode by doing pre-train.
> 
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Monday, November 14, 2016 3:04 AM
> To: Manasi Navare 
> Cc: Cheng, Tony ; intel-gfx@lists.freedesktop.org; Peres, 
> Martin ; dri-de...@lists.freedesktop.org; Deucher, 
> Alexander ; Wentland, Harry 
> 
> Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during 
> modeset
> 
> On Sun, Nov 13, 2016 at 11:43:01PM -0800, Manasi Navare wrote:
> > On Fri, Nov 11, 2016 at 07:42:16PM +, Cheng, Tony wrote:
> > > In case of link training failure and requiring user space to set a lower 
> > > mode, would full mode set address it?  How do we make user mode select 
> > > lower resolution?
> > > 
> > > For example 4k@60Hz monitor, and link training at 4 lane HBR2 fails and 
> > > fallback to 4 lanes HBR, 4k@60 is no longer doable.  I would think 
> > > preventing user mode from seeing 4K@60Hz from the start is a easier and 
> > > more robust solution and requiring user mode to have logic to decide how 
> > > to fallback.
> > >
> > 
> > Hi Tony,
> > 
> > So in case of link training failure, we first call mode_valid that 
> > will use the lower link rate/lane count values based on the link 
> > training fallback to validate the modes and prune the modes that are 
> > higher than the available link. After this is done, then we send the uevent 
> > to userspace indicating that link status is BAD and it will redo a probe 
> > and trigger a modeset for next possible lower resolution.
> 
> Just in case it's not clear: This entire discussion here is only about the 
> userspace-visible abi changes. And I think for the worst-case we need 
> something like this (and Harry at least said on irc that on other os you do 
> something similar already). It of course does not preclude at all that you do 
> additional link-training/probe on initial hotplug. That part is entirely up 
> to drivers (and we might get there on some platforms, but on others it's a 
> real pain to get a link up unfortunately for training, since we need 
> to steal a crtc and do a full modeset).
> -Daniel
> 
> > 
> > Manasi
> > 
> >  
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Friday, November 11, 2016 11:44 AM
> > > To: Cheng, Tony 
> > > Cc: Deucher, Alexander ; 'Jani Nikula' 
> > > ; Manasi Navare 
> > > ; dri-de...@lists.freedesktop.org; 
> > > intel-gfx@lists.freedesktop.org; Wentland, Harry 
> > > ; Peres, Martin 
> > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> > > during modeset
> > > 
> > > On Fri, Nov 11, 2016 at 04:21:58PM +, Cheng, Tony wrote:
> > > > For HDMI, you can yank the cable, plug back in, HDMI will light up 
> > > > without user mode or kernel mode doing anything.
> > > > 
> > > > For DP this is not possible, someone will have to retrain the link when 
> > > > plugging back in or DP will not light up.  We see that on Ubuntu if 
> > > > someone unplug display and plug it back into same connector, we do not 
> > > > get KMS so in this case.  It appears there is some optimizations 
> > > > somewhere in user mode stack which I am not familiar with yet.  dal 
> > > > added workaround to retrain the link to light it back up (after the 
> > > > test training at end of detection).
> > > 
> > > The link should get retrained as the driver should check the link state 
> > > on HPD and retrain if it's not good. At least that's what we do in i915. 
> > > Of course if it's not the same display that got plugged back, the 
> > > retraining might fail. The new property can help with that case as 
> > > userspace would then attempt a full modeset after the failed link 
> > > training.
> > > 
> > > > 
> > > > >From user mode perspective I 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Per-plane rotation leftovers

[Patchwork]

== Series Details ==

Series: drm/i915: Per-plane rotation leftovers
URL   : https://patchwork.freedesktop.org/series/15290/
State : success

== Summary ==

Series 15290v1 drm/i915: Per-plane rotation leftovers
https://patchwork.freedesktop.org/api/1.0/series/15290/revisions/1/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

8670f0f0d91190e0d090ee910c73ed83c37cfef5 drm-intel-nightly: 
2016y-11m-14d-16h-10m-52s UTC integration manifest
86c7280 drm/i915: Add horizontal mirroring support for CHV pipe B planes
c2f2b21 drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup
00f1032 drm/i915: Use & instead if == to check for rotations

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2986/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Kill dp_encoder_is_mst

[ville . syrjala]

From: Ville Syrjälä 

dp_encoder_is_mst flag in the crtc state can be replaced by
intel_crtc_has_type(..., INTEL_OUTPUT_DP_MST). Let's do that.

Cc: Maarten Lankhorst 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 drivers/gpu/drm/i915/intel_dp_mst.c  | 1 -
 drivers/gpu/drm/i915/intel_drv.h | 1 -
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 072a0b1bc9da..5617fb7b2f90 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5496,7 +5496,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
if (intel_crtc->config->has_pch_encoder)
lpt_pch_enable(crtc);
 
-   if (intel_crtc->config->dp_encoder_is_mst)
+   if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(crtc, true);
 
assert_vblank_disabled(crtc);
@@ -5619,7 +5619,7 @@ static void haswell_crtc_disable(struct intel_crtc_state 
*old_crtc_state,
if (!transcoder_is_dsi(cpu_transcoder))
intel_disable_pipe(intel_crtc);
 
-   if (intel_crtc->config->dp_encoder_is_mst)
+   if (intel_crtc_has_type(intel_crtc->config, INTEL_OUTPUT_DP_MST))
intel_ddi_set_vc_payload_alloc(crtc, false);
 
if (!transcoder_is_dsi(cpu_transcoder))
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69e4551..b029d1026a28 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -43,7 +43,6 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int mst_pbn;
 
-   pipe_config->dp_encoder_is_mst = true;
pipe_config->has_pch_encoder = false;
bpp = 24;
/*
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 003afb873b67..75252ecaa613 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -652,7 +652,6 @@ struct intel_crtc_state {
 
bool double_wide;
 
-   bool dp_encoder_is_mst;
int pbn;
 
struct intel_crtc_scaler_state scaler_state;
-- 
2.7.4

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

[Intel-gfx] [PATCH 0/2] drm/i915: A few DP stragglers

[ville . syrjala]

From: Ville Syrjälä 

Reposting a few trivial DP related stragglers, with Jim's irc r-b
slapped on.

Ville Syrjälä (2):
  drm/i915: Kill dp_encoder_is_mst
  drm/i915: Simplify DP port limited color range bit platform checks

 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 drivers/gpu/drm/i915/intel_dp.c  | 7 ++-
 drivers/gpu/drm/i915/intel_dp_mst.c  | 1 -
 drivers/gpu/drm/i915/intel_drv.h | 1 -
 4 files changed, 4 insertions(+), 9 deletions(-)

-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915/GuC: Combine the two kernel parameter into one

[Srivatsa, Anusha]

>-Original Message-
>From: Tvrtko Ursulin [mailto:tvrtko.ursu...@linux.intel.com]
>Sent: Monday, November 14, 2016 1:35 AM
>To: Mcgee, Jeff ; Srivatsa, Anusha
>
>Cc: Ursulin, Tvrtko ; 
>intel-gfx@lists.freedesktop.org;
>Vivi, Rodrigo 
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/GuC: Combine the two kernel
>parameter into one
>
>
>[corrected my email in cc]

Thankyou!

>On 12/11/2016 02:21, Jeff McGee wrote:
>> On Wed, Nov 09, 2016 at 11:11:07AM -0800, Anusha Srivatsa wrote:
>>> Replace i915.enable_guc_loading and i915.enable_guc_submission with a
>>> single parameter - i915.enable_guc. Where:
>>>
>>> -1 : Platform default (Only load GuC)
>>> 0 : Do not use GuC
>>> 1 : Load GuC, do not use Command Submission through GuC
>>> 2 : Load and use GuC for Command Submission
>>>
>> I think this approach could get ugly as we add more GuC functionality
>> and the list of combinations under this one parameter grows.
Yes I see your point.

>> What is the issue we are trying to solve? I thought it was that folks
>> didn't like that we had an option to just load GuC and do nothing with it.
>> Can those folks please comment?

Two parameters was not desired. One parameter that could control the GuC 
functionality was something that led to this patch.

>I am not one of those folks but I also am sure about the proposed change. Same
>concern about extensibility and also usability.
>
>What is the difference between -1 and 1 for example? Is 1 equivalent to the
>current "must use" (2) option? And -1 is equivalent to the current "try to 
>use" (1)?
Right now -1 is for platform default and 1 is for loading and no submission. 
-1: platform default for now is set to do only loading of GuC firmware, unless 
we change that. For now both 1 and -1 are the same.
In future say if for SKL we make loading and submission as default, the code 
has to be changes slightly.

>Then you got proposed 2 (load and use guc) but that does not capture the option
>for built-in GuC firmware Dave has planned for in his version. I don't know if 
>that
>is real or not, just saying
>
>I am also not sure it is so imperative to change this at all. But if people do 
>want to
>change it we should make it really good. :)
I agree. I sent this patch to see what people feel about it and if we have to 
go ahead with these changes.

>One idea could be to hide the guc loading form the user altogether and hence
>improve usability (decrease exposed complexity) by having only two parameters;
>i915.enable_guc_scheduling and i915.enable_huc.
That's a good point. But with this we will have two parameters (which kills the 
point of why the patch was written in the first place), then we can rather 
leave it the way it is. Right?

-Anusha

>Whether or not firmware would be loaded would depend on if either of the two is
>turned on. That would also preserve the option of current fallback or wedge
>behaviour for guc.
>
>Regards,
>
>Tvrtko
___
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: atomic_cdclk_freq fixes

[Patchwork]

== Series Details ==

Series: drm/i915: atomic_cdclk_freq fixes
URL   : https://patchwork.freedesktop.org/series/15288/
State : success

== Summary ==

Series 15288v1 drm/i915: atomic_cdclk_freq fixes
https://patchwork.freedesktop.org/api/1.0/series/15288/revisions/1/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

8670f0f0d91190e0d090ee910c73ed83c37cfef5 drm-intel-nightly: 
2016y-11m-14d-16h-10m-52s UTC integration manifest
9832f6f drm/i915: Simplify error handling in intel_modeset_all_pipes()
ede8100 drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks
97437e8 drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2985/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

[ville . syrjala]

From: Ville Syrjälä 

Move the plane control register rotation setup away from the
coordinate munging code. This will result in neater looking
code once we add reflection support for CHV.

v2: Drop the BIT(), drop some usless parens,

Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-6-git-send-email-ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 24 +---
 drivers/gpu/drm/i915/intel_sprite.c  | 26 ++
 2 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 16b6978662e8..f16766e27b17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3069,6 +3069,9 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
dspcntr |= DISPPLANE_TILED;
 
+   if (rotation & DRM_ROTATE_180)
+   dspcntr |= DISPPLANE_ROTATE_180;
+
if (IS_G4X(dev_priv))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
 
@@ -3079,10 +3082,8 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
intel_compute_tile_offset(, , plane_state, 0);
 
if (rotation & DRM_ROTATE_180) {
-   dspcntr |= DISPPLANE_ROTATE_180;
-
-   x += (crtc_state->pipe_src_w - 1);
-   y += (crtc_state->pipe_src_h - 1);
+   x += crtc_state->pipe_src_w - 1;
+   y += crtc_state->pipe_src_h - 1;
}
 
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
@@ -3174,6 +3175,9 @@ static void ironlake_update_primary_plane(struct 
drm_plane *primary,
if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
dspcntr |= DISPPLANE_TILED;
 
+   if (rotation & DRM_ROTATE_180)
+   dspcntr |= DISPPLANE_ROTATE_180;
+
if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
 
@@ -3182,13 +3186,11 @@ static void ironlake_update_primary_plane(struct 
drm_plane *primary,
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(, , plane_state, 0);
 
-   if (rotation & DRM_ROTATE_180) {
-   dspcntr |= DISPPLANE_ROTATE_180;
-
-   if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
-   x += (crtc_state->pipe_src_w - 1);
-   y += (crtc_state->pipe_src_h - 1);
-   }
+   /* HSW+ does this automagically in hardware */
+   if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv) &&
+   rotation & DRM_ROTATE_180) {
+   x += crtc_state->pipe_src_w - 1;
+   y += crtc_state->pipe_src_h - 1;
}
 
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 37ff13b838ce..ad878ea61640 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -427,6 +427,9 @@ vlv_update_plane(struct drm_plane *dplane,
if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
sprctl |= SP_TILED;
 
+   if (rotation & DRM_ROTATE_180)
+   sprctl |= SP_ROTATE_180;
+
/* Sizes are 0 based */
src_w--;
src_h--;
@@ -437,8 +440,6 @@ vlv_update_plane(struct drm_plane *dplane,
sprsurf_offset = intel_compute_tile_offset(, , plane_state, 0);
 
if (rotation & DRM_ROTATE_180) {
-   sprctl |= SP_ROTATE_180;
-
x += src_w;
y += src_h;
}
@@ -546,6 +547,9 @@ ivb_update_plane(struct drm_plane *plane,
if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
sprctl |= SPRITE_TILED;
 
+   if (rotation & DRM_ROTATE_180)
+   sprctl |= SPRITE_ROTATE_180;
+
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
sprctl &= ~SPRITE_TRICKLE_FEED_DISABLE;
else
@@ -566,14 +570,11 @@ ivb_update_plane(struct drm_plane *plane,
intel_add_fb_offsets(, , plane_state, 0);
sprsurf_offset = intel_compute_tile_offset(, , plane_state, 0);
 
-   if (rotation & DRM_ROTATE_180) {
-   sprctl |= SPRITE_ROTATE_180;
-
-   /* HSW and BDW does this automagically in hardware */
-   if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
-   x += src_w;
-   y += src_h;
-   }
+   /* HSW+ does this automagically in hardware */
+   if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv) &&
+   rotation & DRM_ROTATE_180) {
+   x += src_w;
+  

[Intel-gfx] [PATCH 3/3] drm/i915: Add horizontal mirroring support for CHV pipe B planes

[ville . syrjala]

From: Ville Syrjälä 

The primary and sprite planes on CHV pipe B support horizontal
mirroring. Expose it to the world.

Sadly the hardware ignores the mirror bit when the rotate bit is
set, so we'll have to reject the 180+X case.

v2: Drop the BIT()
v3: Pass dev_priv instead of dev to IS_CHERRYVIEW()

Signed-off-by: Ville Syrjälä 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-7-git-send-email-ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_atomic_plane.c | 9 +
 drivers/gpu/drm/i915/intel_display.c  | 9 +
 drivers/gpu/drm/i915/intel_sprite.c   | 9 +
 3 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 984a6b75c118..ff821649486e 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -106,6 +106,7 @@ intel_plane_destroy_state(struct drm_plane *plane,
 static int intel_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *state)
 {
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
struct drm_crtc *crtc = state->crtc;
struct intel_crtc *intel_crtc;
struct intel_crtc_state *crtc_state;
@@ -167,6 +168,14 @@ static int intel_plane_atomic_check(struct drm_plane 
*plane,
}
}
 
+   /* CHV ignores the mirror bit when the rotate bit is set :( */
+   if (IS_CHERRYVIEW(dev_priv) &&
+   state->rotation & DRM_ROTATE_180 &&
+   state->rotation & DRM_REFLECT_X) {
+   DRM_DEBUG_KMS("Cannot rotate and reflect at the same time\n");
+   return -EINVAL;
+   }
+
intel_state->base.visible = false;
ret = intel_plane->check_plane(plane, crtc_state, intel_state);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f16766e27b17..666a0937fed3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3072,6 +3072,9 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
if (rotation & DRM_ROTATE_180)
dspcntr |= DISPPLANE_ROTATE_180;
 
+   if (rotation & DRM_REFLECT_X)
+   dspcntr |= DISPPLANE_MIRROR;
+
if (IS_G4X(dev_priv))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
 
@@ -3084,6 +3087,8 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
if (rotation & DRM_ROTATE_180) {
x += crtc_state->pipe_src_w - 1;
y += crtc_state->pipe_src_h - 1;
+   } else if (rotation & DRM_REFLECT_X) {
+   x += crtc_state->pipe_src_w - 1;
}
 
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
@@ -15056,6 +15061,10 @@ intel_primary_plane_create(struct drm_i915_private 
*dev_priv, enum pipe pipe)
supported_rotations =
DRM_ROTATE_0 | DRM_ROTATE_90 |
DRM_ROTATE_180 | DRM_ROTATE_270;
+   } else if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
+   supported_rotations =
+   DRM_ROTATE_0 | DRM_ROTATE_180 |
+   DRM_REFLECT_X;
} else if (INTEL_GEN(dev_priv) >= 4) {
supported_rotations =
DRM_ROTATE_0 | DRM_ROTATE_180;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index ad878ea61640..8b2fc67acbba 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -430,6 +430,9 @@ vlv_update_plane(struct drm_plane *dplane,
if (rotation & DRM_ROTATE_180)
sprctl |= SP_ROTATE_180;
 
+   if (rotation & DRM_REFLECT_X)
+   sprctl |= SP_MIRROR;
+
/* Sizes are 0 based */
src_w--;
src_h--;
@@ -442,6 +445,8 @@ vlv_update_plane(struct drm_plane *dplane,
if (rotation & DRM_ROTATE_180) {
x += src_w;
y += src_h;
+   } else if (rotation & DRM_REFLECT_X) {
+   x += src_w;
}
 
linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
@@ -1114,6 +1119,10 @@ intel_sprite_plane_create(struct drm_i915_private 
*dev_priv,
supported_rotations =
DRM_ROTATE_0 | DRM_ROTATE_90 |
DRM_ROTATE_180 | DRM_ROTATE_270;
+   } else if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B) {
+   supported_rotations =
+   DRM_ROTATE_0 | DRM_ROTATE_180 |
+   DRM_REFLECT_X;
} else {
supported_rotations =
DRM_ROTATE_0 | DRM_ROTATE_180;
-- 
2.7.4

___
Intel-gfx mailing list

[Intel-gfx] [PATCH 1/3] drm/i915: Use & instead if == to check for rotations

[ville . syrjala]

From: Ville Syrjälä 

Using == to check for 180 degree rotation only works as long as the
reflection bits aren't set. That will change soon enough for CHV, so
let's stop doing things the wrong way.

v2: Drop the BIT()

Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1477077768-4274-5-git-send-email-ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 8 
 drivers/gpu/drm/i915/intel_sprite.c  | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 072a0b1bc9da..16b6978662e8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3078,7 +3078,7 @@ static void i9xx_update_primary_plane(struct drm_plane 
*primary,
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(, , plane_state, 0);
 
-   if (rotation == DRM_ROTATE_180) {
+   if (rotation & DRM_ROTATE_180) {
dspcntr |= DISPPLANE_ROTATE_180;
 
x += (crtc_state->pipe_src_w - 1);
@@ -3182,7 +3182,7 @@ static void ironlake_update_primary_plane(struct 
drm_plane *primary,
intel_crtc->dspaddr_offset =
intel_compute_tile_offset(, , plane_state, 0);
 
-   if (rotation == DRM_ROTATE_180) {
+   if (rotation & DRM_ROTATE_180) {
dspcntr |= DISPPLANE_ROTATE_180;
 
if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
@@ -10875,7 +10875,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, 
u32 base,
if (HAS_DDI(dev_priv))
cntl |= CURSOR_PIPE_CSC_ENABLE;
 
-   if (plane_state->base.rotation == DRM_ROTATE_180)
+   if (plane_state->base.rotation & DRM_ROTATE_180)
cntl |= CURSOR_ROTATE_180;
}
 
@@ -10921,7 +10921,7 @@ static void intel_crtc_update_cursor(struct drm_crtc 
*crtc,
 
/* ILK+ do this automagically */
if (HAS_GMCH_DISPLAY(dev_priv) &&
-   plane_state->base.rotation == DRM_ROTATE_180) {
+   plane_state->base.rotation & DRM_ROTATE_180) {
base += (plane_state->base.crtc_h *
 plane_state->base.crtc_w - 1) * 4;
}
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 04af4393db5c..37ff13b838ce 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -436,7 +436,7 @@ vlv_update_plane(struct drm_plane *dplane,
intel_add_fb_offsets(, , plane_state, 0);
sprsurf_offset = intel_compute_tile_offset(, , plane_state, 0);
 
-   if (rotation == DRM_ROTATE_180) {
+   if (rotation & DRM_ROTATE_180) {
sprctl |= SP_ROTATE_180;
 
x += src_w;
@@ -566,7 +566,7 @@ ivb_update_plane(struct drm_plane *plane,
intel_add_fb_offsets(, , plane_state, 0);
sprsurf_offset = intel_compute_tile_offset(, , plane_state, 0);
 
-   if (rotation == DRM_ROTATE_180) {
+   if (rotation & DRM_ROTATE_180) {
sprctl |= SPRITE_ROTATE_180;
 
/* HSW and BDW does this automagically in hardware */
@@ -700,7 +700,7 @@ ilk_update_plane(struct drm_plane *plane,
intel_add_fb_offsets(, , plane_state, 0);
dvssurf_offset = intel_compute_tile_offset(, , plane_state, 0);
 
-   if (rotation == DRM_ROTATE_180) {
+   if (rotation & DRM_ROTATE_180) {
dvscntr |= DVS_ROTATE_180;
 
x += src_w;
-- 
2.7.4

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

[Intel-gfx] [PATCH 0/3] drm/i915: Per-plane rotation leftovers

[ville . syrjala]

From: Ville Syrjälä 

Just a repost of the remainder of my per-plane rotation series, just so
I get a proper CI run for them.

Ville Syrjälä (3):
  drm/i915: Use & instead if == to check for rotations
  drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup
  drm/i915: Add horizontal mirroring support for CHV pipe B planes

 drivers/gpu/drm/i915/intel_atomic_plane.c |  9 +++
 drivers/gpu/drm/i915/intel_display.c  | 39 ---
 drivers/gpu/drm/i915/intel_sprite.c   | 39 ---
 3 files changed, 59 insertions(+), 28 deletions(-)

-- 
2.7.4

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

Re: [Intel-gfx] [RFC i-g-t 4/4] Add support for hotplug testing with the Chamelium

[Lyude Paul]

Well I'm definitely in agreement with the idea of using config files
for this. Would be a lot more reliable then these tricks. Will respin
with this added

On Mon, 2016-11-14 at 08:05 +0100, Daniel Vetter wrote:
> On Mon, Nov 07, 2016 at 07:05:16PM -0500, Lyude wrote:
> > 
> > For the purpose of testing things such as hotplugging and bad
> > monitors,
> > the ChromeOS team ended up designing a neat little device known as
> > the
> > Chamelium. More information on this can be found here:
> > 
> > https://www.chromium.org/chromium-os/testing/chamelium
> > 
> > This adds support for a couple of things to intel-gpu-tools:
> >  - igt library functions for connecting to udev and monitoring it
> > for
> >    hotplug events, loosely based off of the unfinished hotplugging
> >    implementation in testdisplay
> >  - Library functions for controlling the chamelium in tests using
> >    xmlrpc. A couple of RPC calls were ommitted here, mainly because
> > they
> >    didn't seem very useful for our needs or because they're just
> > plain
> >    broken
> >  - A set of basic tests using the chamelium.
> > 
> > Because there's no surefire way that I know of where we can map
> > which
> > chamelium port belongs to which port on the system being tested (we
> > could just use hotplugging, but then we'd be relying on something
> > that
> > might be broken on the machine and potentially give false positives
> > for
> > certain tests), most of the chamelium tests will figure out whether
> > or
> > not a connection happened by counting the number of connectors
> > matching
> > the status we're looking for before hotplugging with the chamelium,
> > vs.
> > after hotplugging it.
> > 
> > Tests which require that we know which port belongs to a certain
> > port
> > (such as ones where we actually perform a modeset) will unplug all
> > of
> > the chamelium ports, plug the desired port, then use the first DRM
> > connector with the desired connector type that's marked as
> > connected. In
> > order to ensure we don't end up using the wrong connector, these
> > tests
> > will skip if they find any connectors with the desired type marked
> > as
> > connected before performing the hotplug on the chamelium.
> > 
> > Running these tests requires (of course) a working Chamelium, along
> > with
> > the RPC URL for the chamelium being specified in the environment
> > variable CHAMELIUM_HOST. If no URL is specified, the tests will
> > just
> > skip on their own. As well, tests for connectors which are not
> > actually
> > present on the system or the chamelium will skip on their own as
> > well.
> > 
> > Signed-off-by: Lyude 
> > ---
> >  configure.ac   |  13 +
> >  lib/Makefile.am|  10 +-
> >  lib/igt.h  |   1 +
> >  lib/igt_chamelium.c| 628
> > +
> >  lib/igt_chamelium.h|  77 ++
> 
> Since you typed these nice gtkdocs, please also add it to the .xml in
> docs/ and make sure it looks all good (./autogen.sh --enable-gtk-
> docs).
> 
> Wrt the api itself I think all we need is agreement from Tomeu that
> this
> is the right thing for his chamelium use-cases, too. And Tomeu has
> commit
> rights, so can push this stuff for you.
> -Daniel
> 
> 
> > 
> >  lib/igt_kms.c  | 107 +
> >  lib/igt_kms.h  |  13 +-
> >  scripts/run-tests.sh   |   4 +-
> >  tests/Makefile.am  |   5 +-
> >  tests/Makefile.sources |   1 +
> >  tests/chamelium.c  | 549
> > ++
> >  11 files changed, 1403 insertions(+), 5 deletions(-)
> >  create mode 100644 lib/igt_chamelium.c
> >  create mode 100644 lib/igt_chamelium.h
> >  create mode 100644 tests/chamelium.c
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 735cfd5..88113b2 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -259,6 +259,18 @@ if test "x$with_libunwind" = xyes; then
> >       AC_MSG_ERROR([libunwind not found. Use
> > --without-libunwind to disable libunwind support.]))
> >  fi
> >  
> > +# enable support for using the chamelium
> > +AC_ARG_ENABLE(chamelium,
> > +     AS_HELP_STRING([--without-chamelium],
> > +    [Build tests without chamelium
> > support]),
> > +     [], [with_chamelium=yes])
> > +
> > +AM_CONDITIONAL(HAVE_CHAMELIUM, [test "x$with_chamelium" = xyes])
> > +if test "x$with_chamelium" = xyes; then
> > +   AC_DEFINE(HAVE_CHAMELIUM, 1, [chamelium suport])
> > +   PKG_CHECK_MODULES(XMLRPC, xmlrpc_client)
> > +fi
> > +
> >  # enable debug symbols
> >  AC_ARG_ENABLE(debug,
> >       AS_HELP_STRING([--disable-debug],
> > @@ -356,6 +368,7 @@ echo "   Assembler  :
> > ${enable_assembler}"
> >  echo "   Debugger   : ${enable_debugger}"
> >  echo "   Overlay: X: ${enable_overlay_xlib}, Xv:
> > ${enable_overlay_xvlib}"
> >  echo "   x86-specific tools : ${build_x86}"
> > +echo "   Chamelium support  : 

[Intel-gfx] [PATCH 2/3] drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks

[ville . syrjala]

From: Ville Syrjälä 

A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
actually touching the hardware, in which case we won't force a modeset
on all the pipes, and thus won't lock any of the other pipes either.
That means a parallel plane update on another pipe could be looking at
a stale dev_priv->atomic_cdcdlk_freq and thus fail to notice when the
plane configuration is invalid, or potentially reject a valid update.

To overcome this we must protect writes to atomic_cdclk_freq with
all the crtc locks, and thus for reads any single crtc lock will
be sufficient protection.

Cc: Maarten Lankhorst 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  9 +++-
 drivers/gpu/drm/i915/intel_display.c | 41 +++-
 2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c0f1dfc7119e..66d2950dc657 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1874,7 +1874,14 @@ struct drm_i915_private {
 
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_preferred_vco_freq;
-   unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
+   unsigned int cdclk_freq, max_cdclk_freq;
+
+   /*
+* For reading holding any crtc lock is sufficient,
+* for writing must hold all of them.
+*/
+   unsigned int atomic_cdclk_freq;
+
unsigned int max_dotclk_freq;
unsigned int rawclk_freq;
unsigned int hpll_freq;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 70f3f0b70263..d7a4bc63b05b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13946,13 +13946,32 @@ static int haswell_mode_set_planes_workaround(struct 
drm_atomic_state *state)
return 0;
 }
 
+static int intel_lock_all_pipes(struct drm_atomic_state *state)
+{
+   struct drm_crtc *crtc;
+
+   /* Add all pipes to the state */
+   for_each_crtc(state->dev, crtc) {
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state))
+   return PTR_ERR(crtc_state);
+   }
+
+   return 0;
+}
+
 static int intel_modeset_all_pipes(struct drm_atomic_state *state)
 {
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
int ret = 0;
 
-   /* add all active pipes to the state */
+   /*
+* Add all pipes to the state, and force
+* a modeset on all the active ones.
+*/
for_each_crtc(state->dev, crtc) {
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state))
@@ -14018,12 +14037,24 @@ static int intel_modeset_checks(struct 
drm_atomic_state *state)
if (ret < 0)
return ret;
 
+   /*
+* Writes to dev_priv->atomic_cdclk_freq must protected by
+* holding all the crtc locks, even if we don't end up
+* touching the hardware
+*/
+   if (intel_state->cdclk != dev_priv->atomic_cdclk_freq) {
+   ret = intel_lock_all_pipes(state);
+   if (ret < 0)
+   return ret;
+   }
+
+   /* All pipes must be switched off while we change the cdclk. */
if (intel_state->dev_cdclk != dev_priv->cdclk_freq ||
-   intel_state->cdclk_pll_vco != dev_priv->cdclk_pll.vco)
+   intel_state->cdclk_pll_vco != dev_priv->cdclk_pll.vco) {
ret = intel_modeset_all_pipes(state);
-
-   if (ret < 0)
-   return ret;
+   if (ret < 0)
+   return ret;
+   }
 
DRM_DEBUG_KMS("New cdclk calculated to be atomic %u, actual 
%u\n",
  intel_state->cdclk, intel_state->dev_cdclk);
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/3] drm/i915: Simplify error handling in intel_modeset_all_pipes()

[ville . syrjala]

From: Ville Syrjälä 

No need for the extra break statements and whatnot, just return the
error directly. And tighten the scope of the local variables while at
it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d7a4bc63b05b..b158af6d89b3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13965,14 +13965,15 @@ static int intel_lock_all_pipes(struct 
drm_atomic_state *state)
 static int intel_modeset_all_pipes(struct drm_atomic_state *state)
 {
struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
-   int ret = 0;
 
/*
 * Add all pipes to the state, and force
 * a modeset on all the active ones.
 */
for_each_crtc(state->dev, crtc) {
+   struct drm_crtc_state *crtc_state;
+   int ret;
+
crtc_state = drm_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
@@ -13984,14 +13985,14 @@ static int intel_modeset_all_pipes(struct 
drm_atomic_state *state)
 
ret = drm_atomic_add_affected_connectors(state, crtc);
if (ret)
-   break;
+   return ret;
 
ret = drm_atomic_add_affected_planes(state, crtc);
if (ret)
-   break;
+   return ret;
}
 
-   return ret;
+   return 0;
 }
 
 static int intel_modeset_checks(struct drm_atomic_state *state)
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 1/3] drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things

[ville . syrjala]

From: Ville Syrjälä 

When we end up not recomputing the cdclk, we need to populate
intel_state->cdclk with the "atomic_cdclk_freq" instead of the
current cdclk_freq. When no pipes are active, the actual cdclk_freq
may be lower than what the configuration of the planes and
pipes would require from the point of view of the software state.

This fixes bogus WARNS from skl_max_scale() which is trying to check
the plane software state against the cdclk frequency. So any time
it got called during DPMS off for instance, we might have tripped
the warn if the current mode would have required a higher than
minimum cdclk.

v2: Drop the dev_cdclk stuff (Maarten)

Cc: Maarten Lankhorst 
Cc: Mika Kahola 
Cc: bruno.pag...@ens-lyon.org
Cc: Daniel J Blueman 
Cc: Paul Bolle 
Cc: Joseph Yasi 
Tested-by: Paul Bolle  (v1)
Tested-by: Joseph Yasi  (v1)
Cc: sta...@vger.kernel.org
Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were 
active.")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98214
Signed-off-by: Ville Syrjälä 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e48d9571c99d..70f3f0b70263 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14027,8 +14027,9 @@ static int intel_modeset_checks(struct drm_atomic_state 
*state)
 
DRM_DEBUG_KMS("New cdclk calculated to be atomic %u, actual 
%u\n",
  intel_state->cdclk, intel_state->dev_cdclk);
-   } else
+   } else {
to_intel_atomic_state(state)->cdclk = 
dev_priv->atomic_cdclk_freq;
+   }
 
intel_modeset_clear_plls(state);
 
@@ -14129,8 +14130,9 @@ static int intel_atomic_check(struct drm_device *dev,
 
if (ret)
return ret;
-   } else
-   intel_state->cdclk = dev_priv->cdclk_freq;
+   } else {
+   intel_state->cdclk = dev_priv->atomic_cdclk_freq;
+   }
 
ret = drm_atomic_helper_check_planes(dev, state);
if (ret)
-- 
2.7.4

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

[Intel-gfx] [PATCH 0/3] drm/i915: atomic_cdclk_freq fixes

[ville . syrjala]

From: Ville Syrjälä 

My little fix for populating intel_state->cdclk with
dev_priv->atomic_cdclk_freq became a little meatier after I realized
that we really need to protect it with what is essentially a crtc
rwlock. That is, writers need to hold all the crtc locks, whereas
readers need to hold at least one.

Ville Syrjälä (3):
  drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
  drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks
  drm/i915: Simplify error handling in intel_modeset_all_pipes()

 drivers/gpu/drm/i915/i915_drv.h  |  9 +-
 drivers/gpu/drm/i915/intel_display.c | 60 
 2 files changed, 55 insertions(+), 14 deletions(-)

-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake enabling (rev5)

[Patchwork]

== Series Details ==

Series: Geminilake enabling (rev5)
URL   : https://patchwork.freedesktop.org/series/15118/
State : success

== Summary ==

Series 15118v5 Geminilake enabling
https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/5/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

522cb36969544bb72e3215644c21fac2a60af418 drm-intel-nightly: 
2016y-11m-14d-15h-21m-36s UTC integration manifest
5baa173 drm/i915/glk: Add Geminilake PCI IDs
bdf9462 drm/i915/glk: Introduce Geminilake platform definition
4749323 drm/i915: Create a common GEN9_LP_FEATURE.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2984/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt v3 01/11] igt/perf: add i915 perf stream tests for Haswell

[Robert Bragg]

On Thu, Nov 10, 2016 at 11:03 PM, Matthew Auld  wrote:

> On 11/09, Robert Bragg wrote:
> > +
> > +igt_main
> > +{
> > +igt_skip_on_simulation();
> > +
> > +igt_fixture {
> > +struct stat sb;
> > +int ret;
> > +
> > +drm_fd = drm_open_driver_render(DRIVER_INTEL);
> > +devid = intel_get_drm_devid(drm_fd);
> > +device = drm_get_card();
> > +
> > +igt_require(IS_HASWELL(devid));
> > +igt_require(lookup_hsw_render_basic_id());
> > +
> > +ret = stat("/proc/sys/dev/i915/perf_stream_paranoid",
> );
> > +igt_require(ret == 0);
> > +ret = stat("/proc/sys/dev/i915/oa_max_sample_rate",
> );
> > +igt_require(ret == 0);
> The absence of the above files would indicate a failure in the kernel,
> so would it not be more apt to assert, rather than skip ?
>

The test could be running against an older kernel which won't have these
files and we should skip all the tests in that case.

E.g. Chris asked me to maintain compatibility within the gem_exec_parse
test for older versions of the command parser so I suppose i-g-t tries to
maintain backwards compatibility.

We could potentially require one and assert the other.


> > +
> > +gt_frequency_range_save();
> > +
> > +write_u64_file("/proc/sys/dev/i915/perf_stream_paranoid",
> 1);
> Don't we also want to ensure that the oa_max_sample_rate is also in a
> "good" starting state before we begin, especially since we ensure that
> we leave in its default state when cleaning up ?
>

Explicitly setting the max rate interferes with being able to assert what
the default is, but that's already a problem with the cleanup fixture
explicitly setting the rate.

What I'm doing now is initializing oa_max_sample_rate before tests, as
suggested here, and I've also added a test_sysctl_defaults() test that's
run very early, just after the i915-ref-count test.



>
> Anyway, I think it all looks pretty reasonable to me and it looks like
> we have a good amount of coverage, so you can have my r-b with Chris'
> comment addressed.
>

Thanks, I've moved the ref counting test in front of the first fixture as
suggested by chris (with just the requirements check that the i915-perf
interface exists in another fixture before).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

[Christian König]

Am 14.11.2016 um 12:55 schrieb Chris Wilson:

The current code is subject to a race where we may try to acquire a
reference on a stale fence:

[13703.335118] WARNING: CPU: 1 PID: 14975 at ./include/linux/kref.h:46 
i915_gem_object_wait+0x1a3/0x1c0
[13703.335184] Modules linked in:
[13703.335202] CPU: 1 PID: 14975 Comm: gem_concurrent_ Not tainted 4.9.0-rc4+ 
#26
[13703.335216] Hardware name:  /, BIOS 
PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[13703.335233]  c90002f5bcc8 812807de  

[13703.335257]  c90002f5bd08 81073811 002e8000 
88026bf7c780
[13703.335279]  7fff 0001 88027045a550 
88026bf7c780
[13703.335301] Call Trace:
[13703.335316]  [] dump_stack+0x4d/0x6f
[13703.335331]  [] __warn+0xc1/0xe0
[13703.335343]  [] warn_slowpath_null+0x18/0x20
[13703.335355]  [] i915_gem_object_wait+0x1a3/0x1c0
[13703.335367]  [] i915_gem_set_domain_ioctl+0xcc/0x330
[13703.335386]  [] drm_ioctl+0x1cb/0x410
[13703.335400]  [] ? 
i915_gem_obj_prepare_shmem_write+0x1d0/0x1d0
[13703.335416]  [] ? drm_ioctl+0x2bb/0x410
[13703.335429]  [] do_vfs_ioctl+0x8f/0x5c0
[13703.335442]  [] SyS_ioctl+0x3c/0x70
[13703.335456]  [] entry_SYSCALL_64_fastpath+0x17/0x98
[13703.335558] ---[ end trace fd24176416ba6981 ]---
[13703.382778] general protection fault:  [#1] SMP
[13703.382802] Modules linked in:
[13703.382816] CPU: 1 PID: 14967 Comm: gem_concurrent_ Tainted: GW  
 4.9.0-rc4+ #26
[13703.382828] Hardware name:  /, BIOS 
PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[13703.382841] task: 880275458000 task.stack: c90002f18000
[13703.382849] RIP: 0010:[]  [] 
i915_gem_request_retire+0x2b4/0x320
[13703.382870] RSP: 0018:c90002f1bbc8  EFLAGS: 00010293
[13703.382878] RAX: dead0200 RBX: 88026bf7dce8 RCX: dead0100
[13703.382887] RDX: dead0100 RSI: 88026bf7c930 RDI: 88026bf7dd00
[13703.382897] RBP: c90002f1bbf8 R08:  R09: 88026b89a000
[13703.382905] R10: 0001 R11: 88026bbe8fe0 R12: 88026bf7c000
[13703.382913] R13: 880275af8000 R14: 88026bf7c180 R15: dead0200
[13703.382922] FS:  7f89e787d740() GS:88027fd0() 
knlGS:
[13703.382934] CS:  0010 DS:  ES:  CR0: 80050033
[13703.382942] CR2: 7f9053d2e000 CR3: 00026d414000 CR4: 001006e0
[13703.382951] Stack:
[13703.382958]  880275413000 c90002f1bde8 880275af8000 
880274e8a600
[13703.382976]  880276a06000 c90002f1bde8 c90002f1bc38 
813b48c5
[13703.382995]  c90002f1bc00 c90002f1bde8 88026972a440 

[13703.383021] Call Trace:
[13703.383032]  [] i915_gem_request_alloc+0xa5/0x350
[13703.383043]  [] i915_gem_do_execbuffer.isra.41+0x7b3/0x18b0
[13703.383055]  [] ? i915_gem_object_get_sg+0x25c/0x2b0
[13703.383065]  [] ? i915_gem_object_get_page+0x1d/0x50
[13703.383076]  [] ? i915_gem_pwrite_ioctl+0x66c/0x6d0
[13703.383086]  [] i915_gem_execbuffer2+0x95/0x1e0
[13703.383096]  [] drm_ioctl+0x1cb/0x410
[13703.383105]  [] ? i915_gem_execbuffer+0x2d0/0x2d0
[13703.383117]  [] ? hrtimer_start_range_ns+0x1a0/0x310
[13703.383128]  [] do_vfs_ioctl+0x8f/0x5c0
[13703.383140]  [] ? SyS_timer_settime+0x118/0x1a0
[13703.383150]  [] SyS_ioctl+0x3c/0x70
[13703.383162]  [] entry_SYSCALL_64_fastpath+0x17/0x98
[13703.383172] Code: 49 39 c6 48 8d 70 e8 48 8d 5f e8 75 16 eb 47 48 8d 43 18 48 8b 
53 18 48 89 de 49 39 c6 48 8d 5a e8 74 33 48 8b 56 08 48 8b 46 10 <48> 89 42 08 
48 89 10 f6 46 38 01 48 89 4e 08 4c 89 7e 10 74 cf
[13703.383557] RIP  [] i915_gem_request_retire+0x2b4/0x320
[13703.383570]  RSP 
[13703.383586] ---[ end trace fd24176416ba6982 ]---

This is fixed by using the kref_get_unless_zero() as a full memory
barrier to validate the fence is still the current exclusive fence before
returning it back to the caller. (Note the fix only requires using
dma_fence_get_rcu() and correct handling, but we may as well use the
helper rather than inline equivalent code.)

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal .


---
  include/linux/reservation.h | 15 ++-
  1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 2e313cca08f0..d9706a6f5ae2 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -177,17 +177,14 @@ static inline struct dma_fence *
  reservation_object_get_excl_rcu(struct reservation_object *obj)
  {
struct dma_fence *fence;
-   unsigned seq;
-retry:
-   seq = read_seqcount_begin(>seq);
+
+   if (!rcu_access_pointer(obj->fence_excl))
+   return NULL;
+
rcu_read_lock();
-   fence = rcu_dereference(obj->fence_excl);
-   if (read_seqcount_retry(>seq, seq)) {
-

Re: [Intel-gfx] [PATCH] drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT

[Ville Syrjälä]

On Mon, Nov 14, 2016 at 08:15:56AM +0100, Daniel Vetter wrote:
> On Fri, Nov 11, 2016 at 07:14:24PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT
> > port information apparently didn't survive the reality of buggy VBTs.
> > In this particular case we have a machine with a natice HDMI port, but
> > the VBT telsl us it's a DP++ port based on its capabilities.
> > 
> > The dvo_port information in VBT does claim that we're dealing with a
> > HDMI port though, but we have other machines which do the same even
> > when they actually have DP++ ports. So that piece of information alone
> > isn't sufficient to tell the two apart.
> > 
> > After staring at a bunch of VBTs from various machines, I have to
> > conclude that the only other semi-reliable clue we can use is the
> > presence of the AUX channel in the VBT. On this particular machine
> > AUX channel is specified as zero, whereas on some of the other machines
> > which listed the DP++ port as HDMI have a non-zero AUX channel.
> > 
> > I've also seen VBTs which have dvo_port a DP but have a zero AUX
> > channel. I believe those we need to treat as DP ports, so we'll limit
> > the AUX channel check to just the cases where dvo_port is HDMI.
> > 
> > If we encounter any more serious failures with this heuristic I think
> > we'll have to have to throw it out entirely. But that could mean that
> > there is a risk of type 1 DVI dongle users getting greeted by a
> > black screen, so I'd rather not go there unless absolutely necessary.
> > 
> > Cc: Daniel Otero 
> > Cc: sta...@vger.kernel.org
> > Tested-by: Daniel Otero 
> > Fixes: d61992565bd3 ("drm/i915: Determine DP++ type 1 DVI adaptor presence 
> > based on VBT")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97994
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_bios.c | 32 
> >  drivers/gpu/drm/i915/intel_vbt_defs.h |  3 ++-
> >  2 files changed, 26 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 5ab646ef8c9f..33ed05186810 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1147,7 +1147,7 @@ static void parse_ddi_port(struct drm_i915_private 
> > *dev_priv, enum port port,
> > if (!child)
> > return;
> >  
> > -   aux_channel = child->raw[25];
> > +   aux_channel = child->common.aux_channel;
> > ddc_pin = child->common.ddc_pin;
> >  
> > is_dvi = child->common.device_type & DEVICE_TYPE_TMDS_DVI_SIGNALING;
> > @@ -1677,7 +1677,8 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
> > *dev_priv, enum port port)
> > return false;
> >  }
> >  
> > -bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, 
> > enum port port)
> > +static bool child_dev_is_dp_dual_mode(const union child_device_config 
> > *p_child,
> > + enum port port)
> >  {
> > static const struct {
> > u16 dp, hdmi;
> > @@ -1691,22 +1692,37 @@ bool intel_bios_is_port_dp_dual_mode(struct 
> > drm_i915_private *dev_priv, enum por
> > [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
> > [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> > };
> > -   int i;
> >  
> > if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> > return false;
> >  
> > -   if (!dev_priv->vbt.child_dev_num)
> > +   if ((p_child->common.device_type & DEVICE_TYPE_DP_DUAL_MODE_BITS) !=
> > +   (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
> > +   return false;
> > +
> > +   if (p_child->common.dvo_port == port_mapping[port].dp)
> > +   return true;
> > +
> > +   /* Only accept a HDMI dvo_port as DP++ if it has an AUX channel */
> > +   if (p_child->common.dvo_port == port_mapping[port].hdmi &&
> > +   p_child->common.aux_channel != 0)
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
> > +bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, 
> > enum port port)
> > +{
> > +   int i;
> > +
> > +   if (port == PORT_A)
> > return false;
> 
> We check for PORT_A twice now. Otherwise contains what it says on the tin,
> but no idea whether this is the perfect solution either. Also need to
> check vbt docs for the right bit, but assuming that checks out (I'll
> report on irc), and with the above nitpick fixed:
> 
> Reviewed-by: Daniel Vetter 

11:34 < danvet> vsyrjala, vbt seems to check out too

v2: Remove the duplicate PORT_A check (Daniel)
Fix some typos in the commit message

Pushed to dinq. Thanks for the review.

> 
> >  
> > for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> > const union 

Re: [Intel-gfx] [PATCH v3 01/14] drm/i915: Give each sw_fence its own lockclass

[Chris Wilson]

On Mon, Nov 14, 2016 at 04:48:00PM +0200, Joonas Lahtinen wrote:
> On ma, 2016-11-14 at 08:56 +, Chris Wilson wrote:
> > +   static struct lock_class_key __key; \
> 
> When lockdep is disabled, this becomes zero size. We might still get
> rid of the #fence strings, with some #ifdef, did you measure the
> impact? I remember some for_each_engine_masked cry over bytes.

I was copying mutex_init. To avoid it is not just a little ifdeffery :|

The strings currently cost us around 160 bytes of text.

   textdata bss dec hex filename
12225245077 608 1228209  12bdb1 drivers/gpu/drm/i915/i915.ko
12223645077 608 1228049  12bd11 drivers/gpu/drm/i915/i915.ko

diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c 
b/drivers/gpu/drm/i915/i915_sw_fence.c
index 65fded24a9eb..804af5766650 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence.c
@@ -110,6 +110,9 @@ static void i915_sw_fence_await(struct i915_sw_fence *fence)
WARN_ON(atomic_inc_return(>pending) <= 1);
 }
 
+#ifndef CONFIG_LOCKDEP
+static
+#endif
 void __i915_sw_fence_init(struct i915_sw_fence *fence,
  i915_sw_fence_notify_t fn,
  const char *name,
@@ -123,6 +126,16 @@ void __i915_sw_fence_init(struct i915_sw_fence *fence,
fence->flags = (unsigned long)fn;
 }
 
+#ifndef CONFIG_LOCKDEP
+void i915_sw_fence_init(struct i915_sw_fence *fence,
+   i915_sw_fence_notify_t fn)
+{
+   static struct lock_class_key __key;
+
+   __i915_sw_fence_init(fence, fn, NULL, &__key);
+}
+#endif
+
 void i915_sw_fence_commit(struct i915_sw_fence *fence)
 {
i915_sw_fence_complete(fence);
diff --git a/drivers/gpu/drm/i915/i915_sw_fence.h 
b/drivers/gpu/drm/i915/i915_sw_fence.h
index 23748a1ae6ae..d8510a4b02bd 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence.h
@@ -40,6 +40,7 @@ typedef int (*i915_sw_fence_notify_t)(struct i915_sw_fence *,
  enum i915_sw_fence_notify state);
 #define __i915_sw_fence_call __aligned(4)
 
+#ifdef CONFIG_LOCKDEP
 void __i915_sw_fence_init(struct i915_sw_fence *fence,
  i915_sw_fence_notify_t fn,
  const char *name,
@@ -49,6 +50,10 @@ void __i915_sw_fence_init(struct i915_sw_fence *fence,
\
__i915_sw_fence_init((fence), (fn), #fence, &__key);\
 } while (0)
+#else
+void i915_sw_fence_init(struct i915_sw_fence *fence,
+   i915_sw_fence_notify_t fn);
+#endif
 
 void i915_sw_fence_commit(struct i915_sw_fence *fence);
 

Can we do that more neatly?
-Chris

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

Re: [Intel-gfx] [PATCH v3 01/14] drm/i915: Give each sw_fence its own lockclass

[Joonas Lahtinen]

On ma, 2016-11-14 at 08:56 +, Chris Wilson wrote:
> Localise the static struct lock_class_key to the caller of
> i915_sw_fence_init() so that we create a lock_class instance for each
> unique sw_fence rather than all sw_fences sharing the same
> lock_class. This eliminate some lockdep false positive when using fences
> from within fence callbacks.
> 
> Signed-off-by: Chris Wilson 



> @@ -40,7 +40,16 @@ typedef int (*i915_sw_fence_notify_t)(struct i915_sw_fence 
> *,
>     enum i915_sw_fence_notify state);
>  #define __i915_sw_fence_call __aligned(4)
>  
> -void i915_sw_fence_init(struct i915_sw_fence *fence, i915_sw_fence_notify_t 
> fn);
> +void __i915_sw_fence_init(struct i915_sw_fence *fence,
> +   i915_sw_fence_notify_t fn,
> +   const char *name,
> +   struct lock_class_key *key);
> +#define i915_sw_fence_init(fence, fn) do {   \

Gimme a (line) break here.

> + static struct lock_class_key __key; \

When lockdep is disabled, this becomes zero size. We might still get
rid of the #fence strings, with some #ifdef, did you measure the
impact? I remember some for_each_engine_masked cry over bytes.

> + \
> + __i915_sw_fence_init((fence), fn, #fence, &__key);  \
> +} while (0)
> +

Above addressed, and assuming we're not compiling in extra;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Geminilake enabling (rev5)

[Patchwork]

== Series Details ==

Series: Geminilake enabling (rev5)
URL   : https://patchwork.freedesktop.org/series/15118/
State : success

== Summary ==

Series 15118v5 Geminilake enabling
https://patchwork.freedesktop.org/api/1.0/series/15118/revisions/5/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

02b726586a8230ae7630d909a263776fc11c35ad drm-intel-nightly: 
2016y-11m-14d-13h-35m-49s UTC integration manifest
08e030e drm/i915/glk: Add Geminilake PCI IDs
bbb3d12 drm/i915/glk: Introduce Geminilake platform definition
a5a27da drm/i915: Create a common GEN9_LP_FEATURE.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2983/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx