[Intel-gfx] Information about Intel_GPU_TOP tool
Hello I would like to have more information about the Intel_GPU_TOP tool I have not been able to find much information, but I did found that it is part of the intel-gpu-tools. The system is using Skylake H i7-6700TE I have the following questions 1) Is there a glossary of terms used by the Intel_GPU_TOP tool? 2) The GAM is near 100%. According to this link: https://docs.oracle.com/cd/E53394_01/html/E54763/intel-gpu-top-1.html "Some GPUs report some units as busy when they aren't, such that even when idle and not hung, it will show up as 100% busy." Is this still true or has this bug been corrected? 3) Is the Intel_GPU_TOP tool still in use or it has been replaced by other tool? Best Regards, Adolfo Sanchez ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection
On Thu, 2016-03-17 at 15:55 +, Chris Wilson wrote:
> On Thu, Mar 17, 2016 at 05:46:11PM +0200, Imre Deak wrote:
> > Atm, in case failure injection forces an error the subsequent
> > "*ERROR* failed to init modeset" error message will make automated
> > tests (CI) report this event as a breakage even though the event is
> > expected. To fix this print the error message with debug log level
> > in this case.
> >
> > While at it print the error message for any init failure for
> > consistency.
> >
> > v2:
> > - Include the problematic error message in the commit log, add a
> > request to file an fdo bug to the message (Chris)
>
> And the new one! Helps when cross-referencing a message in dmesg.
> >
> > CC: Chris Wilson
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/i915_dma.c | 14 +++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 68592b0..b4ece9e 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -66,6 +66,14 @@ bool __i915_inject_load_failure(const char
> > *func, int line)
> > return false;
> > }
> >
> > +#define i915_load_error(fmt, ...) do {
> > \
> > + if (i915.inject_load_failure &&
> > \
> > + i915_load_fail_count == i915.inject_load_failure)
> > \
> > + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__);
> > \
> > + else
> > \
> > + DRM_ERROR(fmt, ##__VA_ARGS__);
> > \
> > +} while(0)
> > +
> > static int i915_getparam(struct drm_device *dev, void *data,
> > struct drm_file *file_priv)
> > {
> > @@ -1332,10 +1340,8 @@ int i915_driver_load(struct drm_device *dev,
> > unsigned long flags)
> > }
> >
> > ret = i915_load_modeset_init(dev);
> > - if (ret < 0) {
> > - DRM_ERROR("failed to init modeset\n");
> > + if (ret < 0)
> > goto out_cleanup_vblank;
> > - }
> >
> > i915_driver_register(dev_priv);
> >
> > @@ -1357,6 +1363,8 @@ out_runtime_pm_put:
> > out_free_priv:
> > kfree(dev_priv);
> >
> > + i915_load_error("Device initialization failed (%d), please
> > file a bug at https://bugs.freedesktop.org providing the dmesg log
> > by booting with drm.debug=0xf\n", ret);
>
> 80cols rules still apply to messages :)
>
> "Device initialization failed (%d). "
> "Please file a bug at https://bugs.freedesktop.org/enter_bug.cgi "
> "against DRI/DRM/Intel providing the dmesg log by booting "
> "with drm.debug=0xf\n",
I thought for strings emitted to dmesg it's discouraged, since you
can't easily grep then. But I can make the link more precise.
> I would personally make i915_load_error() a proper function and add
> the "Please..." output there at a lower logging level than ERROR.
Using a function is not straightforward since there is no vprintf like
interface for DRM_ERROR. But I can move that part of the message to
macro.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: add module param "enable_dp_mst"
On Tue, Mar 15, 2016 at 10:14:05AM -0500, Nathan Schulte wrote:
> Adds an (unsafe; auto-kernel-tainting) boolean module parameter to the i915
> drm driver: "enable_dp_mst", which is enabled by default. Disabling the
> parameter forces newly connected DisplayPort sinks to report as not
> supporting multi-stream transport (MST), thus "forcing" the use of
> single-stream transport (SST).
>
> v2: rename parameter to conform to style
> v3: add signoff
>
> Signed-off-by: Nathan Schulte
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_params.c | 5 +
> drivers/gpu/drm/i915/i915_params.h | 1 +
> drivers/gpu/drm/i915/intel_dp.c| 3 +++
> 3 files changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 278c9c4..97691f1 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -56,6 +56,7 @@ struct i915_params i915 __read_mostly = {
> .edp_vswing = 0,
> .enable_guc_submission = false,
> .guc_log_level = -1,
> + .enable_dp_mst = true,
> };
>
> module_param_named(modeset, i915.modeset, int, 0400);
> @@ -201,3 +202,7 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable GuC
> submission (default:false)")
> module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
> MODULE_PARM_DESC(guc_log_level,
> "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
> +
> +module_param_named_unsafe(enable_dp_mst, i915.enable_dp_mst, bool, 0600);
> +MODULE_PARM_DESC(enable_dp_mst,
> + "Enable multi-stream transport (MST) for new DisplayPort sinks.
> (default: true)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index bd5026b..87153b0 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -59,6 +59,7 @@ struct i915_params {
> bool enable_guc_submission;
> bool verbose_state_checks;
> bool nuclear_pageflip;
> + bool enable_dp_mst;
> };
>
> extern struct i915_params i915 __read_mostly;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 0e326e7..ba2d024 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3882,6 +3882,9 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
> {
> u8 buf[1];
>
> + if (!i915.enable_dp_mst)
> + return false;
> +
> if (!intel_dp->can_mst)
> return false;
>
> --
> 2.7.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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] drm/i915: Restrict usage of live status check
Regards
Shashank
On 3/17/2016 9:31 PM, Ville Syrjälä wrote:
On Thu, Mar 17, 2016 at 09:15:39PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 3/17/2016 6:34 PM, Ville Syrjälä wrote:
On Thu, Mar 17, 2016 at 01:29:25PM +0530, Shashank Sharma wrote:
This patch restricts usage of live status check for HDMI detection.
While testing certain (monitor + cable) combinations with various
intel platforms, it seems that live status register is not reliable
on some older devices. So limit the live_status check from VLV onwards.
This fixes a regression introduced in:
commit: 237ed86 "drm/i915: Check live status"
Author: Sonika Jindal
Date: Tue Sep 15 09:44:20 2015 +0530
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index e2dab48..d24d18a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
enum drm_connector_status status;
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
struct drm_i915_private *dev_priv = to_i915(connector->dev);
- bool live_status = false;
+ struct drm_device *dev = connector->dev;
+ bool live_status = true;
unsigned int try;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
@@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
- for (try = 0; !live_status && try < 9; try++) {
- if (try)
- msleep(10);
- live_status = intel_digital_port_connected(dev_priv,
+ /*
+ * Live status check for HDMI detection is not very
+ * reliable on older platforms. So insist the live
+ * status check for EDID read from VLV onwards.
+ */
+ if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
+ for (try = 0; !live_status && try < 9; try++) {
+ if (try)
+ msleep(10);
+ live_status = intel_digital_port_connected(dev_priv,
hdmi_to_dig_port(intel_hdmi));
+ }
+ DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
}
- if (!live_status)
- DRM_DEBUG_KMS("Live status not up!");
-
As I said before, I think this whole thing could be solved with a simple
two-liner here:
+ if (...)
+ live_status = true;
Yes I remember, and I replied on that already that why we would like to
keep the live status check. In fact I would be ok to remove this check
if you can suggest some other way of making this work for other
operating systems/sw platforms.
My two liner would keep the check.
Sorry, I might have not understood you properly.
Do you mean:
if (INTEL_INFO(dev)->gen < 7 && IS_IVYBRIDGE(dev)) {
live_status = true;
} else {
do the same looping for retry;
}
intel_hdmi_unset_edid(connector);
if (intel_hdmi_set_edid(connector, live_status)) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection
On Fri, 2016-03-18 at 10:59 +0200, Joonas Lahtinen wrote: > On pe, 2016-03-18 at 00:18 +0200, Imre Deak wrote: > > On Thu, 2016-03-17 at 22:14 +, Chris Wilson wrote: > > > > > > On Fri, Mar 18, 2016 at 12:09:30AM +0200, Imre Deak wrote: > > > > > > > > On Thu, 2016-03-17 at 21:48 +, Chris Wilson wrote: > > > > > > > > > > I would also like this to be the preferred > > > > > DRM_ERROR reporting mechanism i.e. anytime we emit an ERROR > > > > > we > > > > > should > > > > > be > > > > > encouraging the user to file a bug, and do so in a user > > > > > friendly > > > > > fashion. > > > > Ok, but only in i915 I assume. Should we also convert then all > > > > DRM_ERROR to dev_err - with an *ERROR* prefix - or still use > > > > DRM_ERROR? > > > Within i915. I am thinking along the lines that no DRM_ERROR > > > should > > > exist that doesn't acknowlege that it is a user facing error > > > message > > > (i.e. written in plain English and is informative, and includes a > > > bug > > > reporting reference). So i915_report_error() or somesuch. > > Ok, will give it a go. > > Daniel didn't want i915 debugging/erroring mechanisms to deviate from > core DRM. So I guess this would follow in the same category. > > I'm all in for structuring a coherent debugging/error message logic > and > functions for it and then everyone can follow the suit. The dev_err/dbg method has obvious advantages, like dynamic debug or showing the device instance, so I think that's something we want in any case. I don't see a problem with first rolling it out in i915 then proposing it for more generic use. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] drm/i915/dsi: improved gpio element support for vlv/chv
This series picks up earlier work by Deepak and Yogesh, and splits it up to smaller chunks for easier review and merging. This way we can make progress and get some prep work merged. BXT isn't included yet. BR, Jani. Deepak M (1): drm/i915/dsi: add support for sequence block v3 gpio for VLV Jani Nikula (6): drm/i915/dsi: refer to gpio index instead of gpio to avoid confusion drm/i915/dsi: add support for DSI sequence block v2 gpio element drm/i915/dsi: do not define VLV gpio pad registers separately drm/i915/dsi: abstract VLV gpio element execution to a separate function drm/i915/dsi: clean up the VLV gpio table and definitions drm/i915/chv: add more IOSF port definitions Yogesh Mohan Marimuthu (1): drm/i915/dsi: add support for gpio elements on CHV drivers/gpu/drm/i915/i915_reg.h| 4 + drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 224 - 2 files changed, 158 insertions(+), 70 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Name all intel_ringbuffer instances ring
From: Tvrtko Ursulin
A mix of Coccinelle, sed and manual editing.
v2: Rename engine->buffer as well.
v3: Rebased.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 14 +-
drivers/gpu/drm/i915/i915_drv.h| 4 +-
drivers/gpu/drm/i915/i915_gem.c| 26 ++--
drivers/gpu/drm/i915/i915_gpu_error.c | 6 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-
drivers/gpu/drm/i915/i915_irq.c| 12 +-
drivers/gpu/drm/i915/intel_lrc.c | 239 +++--
drivers/gpu/drm/i915/intel_lrc.h | 14 +-
drivers/gpu/drm/i915/intel_mocs.c | 38 ++---
drivers/gpu/drm/i915/intel_ringbuffer.c| 193 +++
drivers/gpu/drm/i915/intel_ringbuffer.h| 33 ++--
11 files changed, 295 insertions(+), 288 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ccdca2c7d799..9209250e50c5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1933,11 +1933,11 @@ static int i915_gem_framebuffer_info(struct seq_file
*m, void *data)
}
static void describe_ctx_ringbuf(struct seq_file *m,
-struct intel_ringbuffer *ringbuf)
+struct intel_ringbuffer *ring)
{
seq_printf(m, " (ringbuffer, space: %d, head: %u, tail: %u, last head:
%d)",
- ringbuf->space, ringbuf->head, ringbuf->tail,
- ringbuf->last_retired_head);
+ ring->space, ring->head, ring->tail,
+ ring->last_retired_head);
}
static int i915_context_status(struct seq_file *m, void *unused)
@@ -1968,14 +1968,14 @@ static int i915_context_status(struct seq_file *m, void
*unused)
for_each_engine(engine, dev_priv, i) {
struct drm_i915_gem_object *ctx_obj =
ctx->engine[i].state;
- struct intel_ringbuffer *ringbuf =
- ctx->engine[i].ringbuf;
+ struct intel_ringbuffer *ring =
+ ctx->engine[i].ring;
seq_printf(m, "%s: ", engine->name);
if (ctx_obj)
describe_obj(m, ctx_obj);
- if (ringbuf)
- describe_ctx_ringbuf(m, ringbuf);
+ if (ring)
+ describe_ctx_ringbuf(m, ring);
seq_putc(m, '\n');
}
} else {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00c41a4bde2a..1e8e207f72df 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -842,7 +842,7 @@ struct intel_context {
/* Execlists */
struct {
struct drm_i915_gem_object *state;
- struct intel_ringbuffer *ringbuf;
+ struct intel_ringbuffer *ring;
int pin_count;
struct i915_vma *lrc_vma;
u64 lrc_desc;
@@ -2247,7 +2247,7 @@ struct drm_i915_gem_request {
* context.
*/
struct intel_context *ctx;
- struct intel_ringbuffer *ringbuf;
+ struct intel_ringbuffer *ring;
/** Batch buffer related to this request if any (used for
error state dump only) */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a4e015530b0c..e0ec11075bd6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1423,7 +1423,7 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
* Note this requires that we are always called in request
* completion order.
*/
- request->ringbuf->last_retired_head = request->postfix;
+ request->ring->last_retired_head = request->postfix;
list_del_init(&request->list);
i915_gem_request_remove_from_client(request);
@@ -2544,7 +2544,7 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
{
struct intel_engine_cs *engine;
struct drm_i915_private *dev_priv;
- struct intel_ringbuffer *ringbuf;
+ struct intel_ringbuffer *ring;
u32 request_start;
int ret;
@@ -2553,16 +2553,16 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
engine = request->engine;
dev_priv = engine->dev->dev_private;
- ringbuf = request->ringbuf;
+ ring = request->ring;
/*
* To ensure that this call will not fail, space for its emissions
* should already have been reserved in the ring buffer. Let the ring
* know that it is time to use that space up.
Re: [Intel-gfx] [PATCH] drm/i915: Restrict usage of live status check
On Thu, Mar 17, 2016 at 01:29:25PM +0530, Shashank Sharma wrote:
> This patch restricts usage of live status check for HDMI detection.
> While testing certain (monitor + cable) combinations with various
> intel platforms, it seems that live status register is not reliable
> on some older devices. So limit the live_status check from VLV onwards.
>
> This fixes a regression introduced in:
> commit: 237ed86 "drm/i915: Check live status"
> Author: Sonika Jindal
> Date: Tue Sep 15 09:44:20 2015 +0530
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e2dab48..d24d18a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> enum drm_connector_status status;
> struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> - bool live_status = false;
> + struct drm_device *dev = connector->dev;
> + bool live_status = true;
> unsigned int try;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> @@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector,
> bool force)
>
> intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>
> - for (try = 0; !live_status && try < 9; try++) {
> - if (try)
> - msleep(10);
> - live_status = intel_digital_port_connected(dev_priv,
> + /*
> + * Live status check for HDMI detection is not very
> + * reliable on older platforms. So insist the live
> + * status check for EDID read from VLV onwards.
> + */
> + if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
> + for (try = 0; !live_status && try < 9; try++) {
> + if (try)
> + msleep(10);
> + live_status = intel_digital_port_connected(dev_priv,
> hdmi_to_dig_port(intel_hdmi));
> + }
> + DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
> }
>
> - if (!live_status)
> - DRM_DEBUG_KMS("Live status not up!");
> -
As I said before, I think this whole thing could be solved with a simple
two-liner here:
+ if (...)
+ live_status = true;
> intel_hdmi_unset_edid(connector);
>
> if (intel_hdmi_set_edid(connector, live_status)) {
> --
> 1.9.1
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Adaptive backoff delay on link training
Ander Conselvan De Oliveira writes: > [ text/plain ] > On Fri, 2016-03-04 at 14:59 +0200, Ville Syrjälä wrote: >> On Thu, Mar 03, 2016 at 11:27:06AM +0200, Ander Conselvan De Oliveira wrote: >> > (Cc'ing Sivakumar, as he might have some ideas on this) >> > >> > On Fri, 2016-02-26 at 12:54 +0200, Mika Kuoppala wrote: >> > > If the panel don't give us the information how long to wait >> > > before starting a new link training phase, it is not productive >> > > to poke it at 100us or 400us intervals and then give up if it >> > > fails to respond in time. Instead gradually increase the training >> > > delay so that we reach the slower kind and get display up. >> > > >> > > This was needed to reach panel: >> > > >> > > : 12 14 c4 41 00 00 01 c0 02 00 00 00 1f 0b 00 >> > > 0070: 01 00 >> > > 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> > > 0100: 14 84 00 00 00 00 00 00 01 10 00 >> > > 0200: 01 00 00 00 80 00 00 00 >> > > 0600: 01 >> > > 0700: 02 >> > > 0701: b7 f6 00 00 >> > > 0720: 00 04 02 00 0a 04 0a 00 1b 00 00 01 00 ff ff 03 >> > > 0732: 04 10 >> > > >> > > on kbl (8086:591e) >> > >> > I poked at the machine in question. Here's what I found out: >> > >> > - having the delay fixed at 16ms with all the retries in this patch is >> > enough to >> > achieve clock recovery; >> > - forcing different iboost levels doesn't reduce the number of tries done >> > with >> > the code in this patch; >> >> Did you try low vswing vs. not? > > I completely missed that. Judging from the log below, dev_priv->edp_low_vswing > was set by the bios, since vswing level 3 is being used. Should try booting > with > i915.edp_vswing=2. > With todays nightly and i915.edp_vswing=2 we get display. This patch can be thus ignored. -Mika > Ander > >> > - clock recovery fails because lane 0 fails to achieve clock recovery most >> > of >> > the time, while the other lanes succeed. >> > >> > The log below was obtained with a patch to log the link status after each >> > clock >> > recovery delay. >> > >> > >> > [drm:intel_dp_set_signal_levels] Using signal levels >> > [drm:intel_dp_set_signal_levels] Using vswing level 0 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 00 00 80 00 11 11 >> > [drm:intel_dp_set_signal_levels] Using signal levels 0400 >> > [drm:intel_dp_set_signal_levels] Using vswing level 1 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 10 11 80 00 12 11 >> > [drm:intel_dp_set_signal_levels] Using signal levels 0700 >> > [drm:intel_dp_set_signal_levels] Using vswing level 2 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 10 11 80 00 23 22 >> > [drm:intel_dp_set_signal_levels] Using signal levels 0900 >> > [drm:intel_dp_set_signal_levels] Using vswing level 3 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 10 10 80 00 33 33 >> > >> > [drm:intel_dp_set_signal_levels] Using signal levels >> > [drm:intel_dp_set_signal_levels] Using vswing level 0 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 00 00 80 00 11 11 >> > [drm:intel_dp_set_signal_levels] Using signal levels 0400 >> > [drm:intel_dp_set_signal_levels] Using vswing level 1 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 10 10 80 00 12 12 >> > [drm:intel_dp_set_signal_levels] Using signal levels 0700 >> > [drm:intel_dp_set_signal_levels] Using vswing level 2 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 10 11 80 00 23 22 >> > [drm:intel_dp_set_signal_levels] Using signal levels 0900 >> > [drm:intel_dp_set_signal_levels] Using vswing level 3 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 10 10 80 00 33 33 >> > >> > [drm:intel_dp_set_signal_levels] Using signal levels >> > [drm:intel_dp_set_signal_levels] Using vswing level 0 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 00 00 80 00 11 11 >> > [drm:intel_dp_set_signal_levels] Using signal levels 0400 >> > [drm:intel_dp_set_signal_levels] Using vswing level 1 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [drm:intel_dp_link_training_clock_recovery] link status: 10 10 80 00 12 12 >> > [drm:intel_dp_set_signal_levels] Using signal levels 0700 >> > [drm:intel_dp_set_signal_levels] Using vswing level 2 >> > [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 >> > [d
Re: [Intel-gfx] [PATCH] sna: revert the short-curcuit breaking XShmGetImage
>> I tested on: >> i5-4570 (Haswell) and B85 Chipset >> Fedora 24 (Developmental Branch) x86_64 >> Cinnamon 2.8.7 >> xf86-video-intel commit 74cd4d09ae051d3a1f4cb9fe29e656b044f03ece xf86-video-intel configure: --enable-kms-only --with-default-dri=3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection
On Thu, 2016-03-17 at 22:14 +, Chris Wilson wrote: > On Fri, Mar 18, 2016 at 12:09:30AM +0200, Imre Deak wrote: > > On Thu, 2016-03-17 at 21:48 +, Chris Wilson wrote: > > > I would also like this to be the preferred > > > DRM_ERROR reporting mechanism i.e. anytime we emit an ERROR we > > > should > > > be > > > encouraging the user to file a bug, and do so in a user friendly > > > fashion. > > > > Ok, but only in i915 I assume. Should we also convert then all > > DRM_ERROR to dev_err - with an *ERROR* prefix - or still use > > DRM_ERROR? > > Within i915. I am thinking along the lines that no DRM_ERROR should > exist that doesn't acknowlege that it is a user facing error message > (i.e. written in plain English and is informative, and includes a bug > reporting reference). So i915_report_error() or somesuch. Ok, will give it a go. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] sna: revert the short-curcuit breaking XShmGetImage
On Fri, Mar 18, 2016 at 06:13:14PM +0900, Shu Yokoyama wrote: > The short-curcuit introduced by commit 963b5bb (later modified by commit > aacc344) breaks XShmGetImage(). > Images captured by ffmpeg's x11grab or x11vnc become choppy, while I use > Cinnamon Desktop Environment. The idea there (with an exported object) is that bo->rq should not be NULL as we use that in many places to determine if the buffer is busy or not. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915: Rename dev_priv->gtt to dev_priv->ggtt
Refer to Global GTT consistently as GGTT, thus rename dev_priv->gtt
to dev_priv->ggtt and struct i915_gtt to struct i915_ggtt.
Fix a couple of whitespace problems while at it.
v2:
- Fix a typo in commit message.
Reviewed-by: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c| 8 +-
drivers/gpu/drm/i915/i915_dma.c| 18 ++--
drivers/gpu/drm/i915/i915_drv.h| 4 +-
drivers/gpu/drm/i915/i915_gem.c| 16 ++--
drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +-
drivers/gpu/drm/i915/i915_gem_gtt.c| 147 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h| 9 +-
drivers/gpu/drm/i915/i915_gem_stolen.c | 50 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 10 +-
drivers/gpu/drm/i915/i915_vgpu.c | 14 +--
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_fbc.c | 4 +-
drivers/gpu/drm/i915/intel_fbdev.c | 6 +-
drivers/gpu/drm/i915/intel_overlay.c | 4 +-
drivers/gpu/drm/i915/intel_pm.c| 10 +-
drivers/gpu/drm/i915/intel_ringbuffer.c| 2 +-
17 files changed, 156 insertions(+), 158 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ccdca2c..e0ba3e3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -203,7 +203,7 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
struct list_head *head;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct i915_address_space *vm = &dev_priv->gtt.base;
+ struct i915_address_space *vm = &dev_priv->ggtt.base;
struct i915_vma *vma;
u64 total_obj_size, total_gtt_size;
int count, ret;
@@ -433,7 +433,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
u32 count, mappable_count, purgeable_count;
u64 size, mappable_size, purgeable_size;
struct drm_i915_gem_object *obj;
- struct i915_address_space *vm = &dev_priv->gtt.base;
+ struct i915_address_space *vm = &dev_priv->ggtt.base;
struct drm_file *file;
struct i915_vma *vma;
int ret;
@@ -492,8 +492,8 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
count, size);
seq_printf(m, "%llu [%llu] gtt total\n",
- dev_priv->gtt.base.total,
- (u64)dev_priv->gtt.mappable_end - dev_priv->gtt.base.start);
+ dev_priv->ggtt.base.total,
+ (u64)dev_priv->ggtt.mappable_end -
dev_priv->ggtt.base.start);
seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 68592b0..3565163 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -491,8 +491,8 @@ static int i915_kick_out_firmware_fb(struct
drm_i915_private *dev_priv)
if (!ap)
return -ENOMEM;
- ap->ranges[0].base = dev_priv->gtt.mappable_base;
- ap->ranges[0].size = dev_priv->gtt.mappable_end;
+ ap->ranges[0].base = dev_priv->ggtt.mappable_base;
+ ap->ranges[0].size = dev_priv->ggtt.mappable_end;
primary =
pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
@@ -1172,17 +1172,17 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
if (IS_BROADWATER(dev) || IS_CRESTLINE(dev))
dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(32));
- aperture_size = dev_priv->gtt.mappable_end;
+ aperture_size = dev_priv->ggtt.mappable_end;
- dev_priv->gtt.mappable =
- io_mapping_create_wc(dev_priv->gtt.mappable_base,
+ dev_priv->ggtt.mappable =
+ io_mapping_create_wc(dev_priv->ggtt.mappable_base,
aperture_size);
- if (dev_priv->gtt.mappable == NULL) {
+ if (dev_priv->ggtt.mappable == NULL) {
ret = -EIO;
goto out_gtt;
}
- dev_priv->gtt.mtrr = arch_phys_wc_add(dev_priv->gtt.mappable_base,
+ dev_priv->ggtt.mtrr = arch_phys_wc_add(dev_priv->ggtt.mappable_base,
aperture_size);
pm_qos_add_request(&dev_priv->pm_qos, PM_QOS_CPU_DMA_LATENCY,
@@ -1230,8 +1230,8 @@ static void i915_driver_cleanup_hw(struct
drm_i915_private *dev_priv)
pci_disable_msi(dev->pdev);
pm_qos_remove_request(&dev_priv->pm_qos);
- arch_phys_wc_del(dev_priv->gtt.mtrr);
- io_mapping_free(dev_priv->gtt.mappable);
+ arch_phys_wc_del(dev_priv->ggtt.mtrr);
+ io_mapping_free(dev_priv->ggtt.mappable);
i915_global_gtt_cleanup(dev);
}
diff --git a/drivers/gpu/dr
[Intel-gfx] [PATCH 2/3] drm/i915: Rename dev_priv->gtt to dev_priv->ggtt
Refer to Global GTT consistencly as GGTT, thus rename dev_priv->gtt
to dev_priv->ggtt and struct i915_gtt to struct i915_ggtt.
Fix a couple of whitespace problems while at it.
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c| 8 +-
drivers/gpu/drm/i915/i915_dma.c| 18 ++--
drivers/gpu/drm/i915/i915_drv.h| 4 +-
drivers/gpu/drm/i915/i915_gem.c| 16 ++--
drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +-
drivers/gpu/drm/i915/i915_gem_gtt.c| 147 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h| 9 +-
drivers/gpu/drm/i915/i915_gem_stolen.c | 50 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 10 +-
drivers/gpu/drm/i915/i915_vgpu.c | 14 +--
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_fbc.c | 4 +-
drivers/gpu/drm/i915/intel_fbdev.c | 6 +-
drivers/gpu/drm/i915/intel_overlay.c | 4 +-
drivers/gpu/drm/i915/intel_pm.c| 10 +-
drivers/gpu/drm/i915/intel_ringbuffer.c| 2 +-
17 files changed, 156 insertions(+), 158 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ccdca2c..e0ba3e3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -203,7 +203,7 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
struct list_head *head;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct i915_address_space *vm = &dev_priv->gtt.base;
+ struct i915_address_space *vm = &dev_priv->ggtt.base;
struct i915_vma *vma;
u64 total_obj_size, total_gtt_size;
int count, ret;
@@ -433,7 +433,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
u32 count, mappable_count, purgeable_count;
u64 size, mappable_size, purgeable_size;
struct drm_i915_gem_object *obj;
- struct i915_address_space *vm = &dev_priv->gtt.base;
+ struct i915_address_space *vm = &dev_priv->ggtt.base;
struct drm_file *file;
struct i915_vma *vma;
int ret;
@@ -492,8 +492,8 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
count, size);
seq_printf(m, "%llu [%llu] gtt total\n",
- dev_priv->gtt.base.total,
- (u64)dev_priv->gtt.mappable_end - dev_priv->gtt.base.start);
+ dev_priv->ggtt.base.total,
+ (u64)dev_priv->ggtt.mappable_end -
dev_priv->ggtt.base.start);
seq_putc(m, '\n');
print_batch_pool_stats(m, dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 68592b0..3565163 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -491,8 +491,8 @@ static int i915_kick_out_firmware_fb(struct
drm_i915_private *dev_priv)
if (!ap)
return -ENOMEM;
- ap->ranges[0].base = dev_priv->gtt.mappable_base;
- ap->ranges[0].size = dev_priv->gtt.mappable_end;
+ ap->ranges[0].base = dev_priv->ggtt.mappable_base;
+ ap->ranges[0].size = dev_priv->ggtt.mappable_end;
primary =
pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW;
@@ -1172,17 +1172,17 @@ static int i915_driver_init_hw(struct drm_i915_private
*dev_priv)
if (IS_BROADWATER(dev) || IS_CRESTLINE(dev))
dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(32));
- aperture_size = dev_priv->gtt.mappable_end;
+ aperture_size = dev_priv->ggtt.mappable_end;
- dev_priv->gtt.mappable =
- io_mapping_create_wc(dev_priv->gtt.mappable_base,
+ dev_priv->ggtt.mappable =
+ io_mapping_create_wc(dev_priv->ggtt.mappable_base,
aperture_size);
- if (dev_priv->gtt.mappable == NULL) {
+ if (dev_priv->ggtt.mappable == NULL) {
ret = -EIO;
goto out_gtt;
}
- dev_priv->gtt.mtrr = arch_phys_wc_add(dev_priv->gtt.mappable_base,
+ dev_priv->ggtt.mtrr = arch_phys_wc_add(dev_priv->ggtt.mappable_base,
aperture_size);
pm_qos_add_request(&dev_priv->pm_qos, PM_QOS_CPU_DMA_LATENCY,
@@ -1230,8 +1230,8 @@ static void i915_driver_cleanup_hw(struct
drm_i915_private *dev_priv)
pci_disable_msi(dev->pdev);
pm_qos_remove_request(&dev_priv->pm_qos);
- arch_phys_wc_del(dev_priv->gtt.mtrr);
- io_mapping_free(dev_priv->gtt.mappable);
+ arch_phys_wc_del(dev_priv->ggtt.mtrr);
+ io_mapping_free(dev_priv->ggtt.mappable);
i915_global_gtt_cleanup(dev);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 00c41a
Re: [Intel-gfx] [PATCH v3 00/19] Split driver init step to phases
On Wed, Mar 16, 2016 at 01:38:49PM +0200, Imre Deak wrote: > This is v3 of [1]. It includes now the fault injection patches Chris > requested and addresses comments from Daniel and Joonas. Since IGT has > by now an updated drv_module_reload_basic too using load failure > injection, CI hopefully catches any problems introduced by this > patchset. > > CC: Chris Wilson > CC: Jani Nikula > CC: Ander Conselvan de Oliveira > CC: Joonas Lahtinen > CC: Daniel Vetter > > [1] > https://lists.freedesktop.org/archives/intel-gfx/2016-March/089596.html > > Imre Deak (19): > Fix MCHBAR cleanup on the driver init error path > drm/i915: Move load time PCH detect, DPIO, power domain SW init > earlier > drm/i915: Move load time IRQ SW init earlier > drm/i915: Move load time init of display/audio hooks earlier > drm/i915: Move load time init of clock gating hooks earlier > drm/i915: Move load time runtime device info init earlier > drm/i915: Move load time gem_load_init earlier > drm/i915: Move load time runtime PM get later > drm/i915: Move load time shrinker registration later > drm/i915: Move load time audio component registration earlier > drm/i915: Move unload time display power domain uninit later > drm/i915: Move unload time GTT, MSI IRQ cleanup later > drm/i915: Move unload time opregion unregistration earlier > drm/i915: Split out load time early initialization > drm/i915: Split out load time MMIO initialization > drm/i915: Split out load time HW initialization > drm/i915: Split out load time interface registration > drm/i915: Fix power domain HW state cleanup on error path > drm/i915: Add fault injection support A couple of very minor tweaks, nevertheless Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Rename local struct intel_engine_cs variables
On 16/03/16 15:40, Ville Syrjälä wrote: On Wed, Mar 16, 2016 at 03:35:13PM +, Tvrtko Ursulin wrote: On 16/03/16 15:01, Patchwork wrote: == Series Details == Series: series starting with [1/5] drm/i915: Rename local struct intel_engine_cs variables URL : https://patchwork.freedesktop.org/series/4508/ State : failure == Summary == Series 4508v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/4508/revisions/1/mbox/ Test drv_module_reload_basic: skip -> PASS (bdw-nuci7) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (ivb-t430s) Unrelated https://bugs.freedesktop.org/show_bug.cgi?id=94294 I'd like people to add a bit more information to these analysis mails. If there's just the bugzilla link I actually have to open it before I can see what the problem was. Makes it harder to keep on top what the most common BAT problems are. Yeah in principle I agree but some of these are the usual suspects which have been dragging for so long it would take an iron will (or something nastier) to keep repeating the same analysis over and over again. Sometimes I remember and add a link to new CI logs to the relevant BZ instance which is probably more useful for people looking at BAT marked entries (which are all critical anyway) to gather enough data points when debugging. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/6] drm/i915: Use to_i915() instead of guc_to_i915()
The convenience of saving a few characters by using a consistent
interface to obtain our drm_i915_private struct from intel_guc.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 4 +++-
drivers/gpu/drm/i915/i915_guc_submission.c | 23 ++-
2 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 92365f047e53..d5fa42c96110 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1982,7 +1982,7 @@ static inline struct drm_i915_private *dev_to_i915(struct
device *dev)
return __to_i915(dev_get_drvdata(dev));
}
-static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+static inline struct drm_i915_private *__guc_to_i915(struct intel_guc *guc)
{
return container_of(guc, struct drm_i915_private, guc);
}
@@ -2463,6 +2463,8 @@ struct drm_i915_cmd_table {
__p = __to_i915((struct drm_device *)p); \
else if (__builtin_types_compatible_p(typeof(*p), struct
drm_i915_gem_object)) \
__p = __obj_to_i915((struct drm_i915_gem_object *)p); \
+ else if (__builtin_types_compatible_p(typeof(*p), struct intel_guc)) \
+ __p = __guc_to_i915((struct intel_guc *)p); \
else \
BUILD_BUG(); \
__p; \
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ae1f58d073f2..850aee78c40f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -77,7 +77,7 @@ static inline bool host2guc_action_response(struct
drm_i915_private *dev_priv,
static int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_i915_private *dev_priv = to_i915(guc);
u32 status;
int i;
int ret;
@@ -152,7 +152,7 @@ static int host2guc_release_doorbell(struct intel_guc *guc,
static int host2guc_sample_forcewake(struct intel_guc *guc,
struct i915_guc_client *client)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_i915_private *dev_priv = to_i915(guc);
struct drm_device *dev = dev_priv->dev;
u32 data[2];
@@ -254,7 +254,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
static void guc_disable_doorbell(struct intel_guc *guc,
struct i915_guc_client *client)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_i915_private *dev_priv = to_i915(guc);
struct guc_doorbell_info *doorbell;
void *base;
i915_reg_t drbreg = GEN8_DRBREGL(client->doorbell_id);
@@ -376,7 +376,6 @@ static void guc_init_proc_desc(struct intel_guc *guc,
static void guc_init_ctx_desc(struct intel_guc *guc,
struct i915_guc_client *client)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct intel_engine_cs *engine;
struct intel_context *ctx = client->owner;
struct guc_context_desc desc;
@@ -390,7 +389,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.priority = client->priority;
desc.db_id = client->doorbell_id;
- for_each_engine(engine, dev_priv, i) {
+ for_each_engine(engine, guc, i) {
struct guc_execlist_context *lrc = &desc.lrc[engine->guc_id];
struct drm_i915_gem_object *obj;
uint64_t ctx_desc;
@@ -772,7 +771,6 @@ err:
static void guc_create_log(struct intel_guc *guc)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct drm_i915_gem_object *obj;
unsigned long offset;
uint32_t size, flags;
@@ -791,7 +789,7 @@ static void guc_create_log(struct intel_guc *guc)
obj = guc->log_obj;
if (!obj) {
- obj = gem_allocate_guc_obj(dev_priv->dev, size);
+ obj = gem_allocate_guc_obj(to_i915(guc)->dev, size);
if (!obj) {
/* logging will be off */
i915.guc_log_level = -1;
@@ -835,7 +833,6 @@ static void init_guc_policies(struct guc_policies *policies)
static void guc_create_ads(struct intel_guc *guc)
{
- struct drm_i915_private *dev_priv = guc_to_i915(guc);
struct drm_i915_gem_object *obj;
struct guc_ads *ads;
struct guc_policies *policies;
@@ -851,7 +848,7 @@ static void guc_create_ads(struct intel_guc *guc)
obj = guc->ads_obj;
if (!obj) {
- obj = gem_allocate_guc_obj(dev_priv->dev, PAGE_ALIGN(size));
+ obj = gem_allocate_guc_obj(to_i915(guc)->dev, PAGE_ALIGN(size));
if (!obj)
return;
@@ -868,10 +865,10 @@ static void guc_create_ads(struct intel_guc *guc)
* so its address won't change afte
Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection
On Thu, Mar 17, 2016 at 06:08:05PM +0200, Imre Deak wrote: > On Thu, 2016-03-17 at 15:55 +, Chris Wilson wrote: > > 80cols rules still apply to messages :) > > > > "Device initialization failed (%d). " > > "Please file a bug at https://bugs.freedesktop.org/enter_bug.cgi " > > "against DRI/DRM/Intel providing the dmesg log by booting " > > "with drm.debug=0xf\n", > > I thought for strings emitted to dmesg it's discouraged, since you > can't easily grep then. But I can make the link more precise. Hmm, we haven't abided by that. I don't mind really :) > > I would personally make i915_load_error() a proper function and add > > the "Please..." output there at a lower logging level than ERROR. > > Using a function is not straightforward since there is no vprintf like > interface for DRM_ERROR. But I can move that part of the message to > macro. In that case, I'm happy enough with ditching the DRM_ERROR here and go with dev_err(). Another nail in the DRM_ERROR coffin. -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 1/4] drm/i915: Remove unused variable in i915_gem_request_add_to_client
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 31652c1da761..9c4d9c186d91 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1370,7 +1370,6 @@ out:
int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
struct drm_file *file)
{
- struct drm_i915_private *dev_private;
struct drm_i915_file_private *file_priv;
WARN_ON(!req || !file || req->file_priv);
@@ -1381,7 +1380,6 @@ int i915_gem_request_add_to_client(struct
drm_i915_gem_request *req,
if (req->file_priv)
return -EINVAL;
- dev_private = req->engine->dev->dev_private;
file_priv = file->driver_priv;
spin_lock(&file_priv->mm.lock);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Release power ref after updating wm
On Wed, Mar 16, 2016 at 05:15:31PM +0200, Imre Deak wrote: > Matt has a similar fix already on the list, Matt/Ville what's the plan > with that? Could we have a stop-gap solution? > > --Imre Yeah, I wrote two separate patches that would both be fixes for that issue. One of them moved the PM reference drop like the patch below; the other wrapped the actual watermark programming in a PM get_if_enabled() call to make sure the reference was held throughout the watermark programming, or skipped the watermark programming entirely if we were already fully powered down. Neither patch got a reviewed-by and I got wrapped up in something else and forgot to poke anyone. I don't have a strong preference either way on which fix is best (they should both be fine for now I think). I think longer-term we'll eventually need the second approach above once we allow the watermark programming to happen asynchronously via a workqueue task. Matt > > On Wed, 2016-03-16 at 17:11 +0200, Gabriel Feceoru wrote: > > On HSW/BDW there are random dmesg-warn errors while running kms > > tests, like: > > > > [90587.867077] Call Trace: > > [90587.867085] [] dump_stack+0x67/0x99 > > [90587.867094] [] warn_slowpath_common+0x81/0xc0 > > [90587.867099] [] warn_slowpath_fmt+0x47/0x50 > > [90587.867150] [] hsw_write32+0x280/0x290 [i915] > > [90587.867186] [] _ilk_disable_lp_wm+0x98/0xd0 > > [i915] > > [90587.867222] [] > > ilk_program_watermarks+0x4a2/0x940 [i915] > > [90587.867260] [] > > ilk_optimize_watermarks+0x50/0x70 [i915] > > [90587.867311] [] intel_atomic_commit+0x742/0x2170 > > [i915] > > [90587.867319] [] ? wait_woken+0xa0/0xa0 > > [90587.867326] [] drm_atomic_commit+0x32/0x50 > > [90587.867333] [] > > drm_atomic_helper_connector_dpms+0xe9/0x1a0 > > [90587.867340] [] > > drm_mode_obj_set_property_ioctl+0x21d/0x230 > > [90587.867346] [] > > drm_mode_connector_property_set_ioctl+0x2b/0x30 > > [90587.867352] [] drm_ioctl+0x236/0x4f0 > > [90587.867358] [] ? > > drm_mode_obj_set_property_ioctl+0x230/0x230 > > [90587.867366] [] do_vfs_ioctl+0x8e/0x680 > > [90587.867372] [] ? __fget_light+0x6a/0x90 > > [90587.867378] [] SyS_ioctl+0x3c/0x70 > > [90587.867386] [] > > entry_SYSCALL_64_fastpath+0x16/0x73 > > > > Since writing the watermarks requires MMIO access, this should be > > done before > > releasing the power reference. > > > > This clears the flip-flops in kms tests on HSW/BDW. > > > > Signed-off-by: Gabriel Feceoru > > --- > > drivers/gpu/drm/i915/intel_display.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index ce55f0b..b141e52 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -13631,9 +13631,6 @@ static int intel_atomic_commit(struct > > drm_device *dev, > > modeset_put_power_domains(dev_priv, > > put_domains[i]); > > } > > > > - if (intel_state->modeset) > > - intel_display_power_put(dev_priv, > > POWER_DOMAIN_MODESET); > > - > > /* > > * Now that the vblank has passed, we can go ahead and > > program the > > * optimal watermarks on platforms that need two-step > > watermark > > @@ -13648,6 +13645,9 @@ static int intel_atomic_commit(struct > > drm_device *dev, > > dev_priv- > > >display.optimize_watermarks(intel_cstate); > > } > > > > + if (intel_state->modeset) > > + intel_display_power_put(dev_priv, > > POWER_DOMAIN_MODESET); > > + > > mutex_lock(&dev->struct_mutex); > > drm_atomic_helper_cleanup_planes(dev, state); > > mutex_unlock(&dev->struct_mutex); -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection
On Thu, 2016-03-17 at 19:41 +, Chris Wilson wrote: > On Thu, Mar 17, 2016 at 06:08:05PM +0200, Imre Deak wrote: > > On Thu, 2016-03-17 at 15:55 +, Chris Wilson wrote: > > > 80cols rules still apply to messages :) > > > > > > "Device initialization failed (%d). " > > > "Please file a bug at https://bugs.freedesktop.org/enter_bug.cgi > > > " > > > "against DRI/DRM/Intel providing the dmesg log by booting " > > > "with drm.debug=0xf\n", > > > > I thought for strings emitted to dmesg it's discouraged, since you > > can't easily grep then. But I can make the link more precise. > > Hmm, we haven't abided by that. I don't mind really :) Ok, will follow this rule then. > > > I would personally make i915_load_error() a proper function and > > > add > > > the "Please..." output there at a lower logging level than ERROR. > > > > Using a function is not straightforward since there is no vprintf > > like > > interface for DRM_ERROR. But I can move that part of the message to > > macro. > > In that case, I'm happy enough with ditching the DRM_ERROR here and > go > with dev_err(). Another nail in the DRM_ERROR coffin. Hm, there doesn't seem to be vprintf like dev_err either. And dev_dbg depends on CONFIG_DEBUG while DRM_DEBUG doesn't. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] dim: Avoid false positives with BUG detection
On 17/03/16 11:27, Jani Nikula wrote:
On Thu, 17 Mar 2016, Tvrtko Ursulin wrote:
[ text/plain ]
On 11/03/16 15:31, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Makes sure that the diff line adding the BUG is not immediately
preceded by the diff line removing the BUG. Or in other words,
avoids false positives when existing BUG is edited.
v2: Sent the incomplete version out...
Signed-off-by: Tvrtko Ursulin
---
dim | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dim b/dim
index 1e7622a1e902..5392c64bf5b4 100755
--- a/dim
+++ b/dim
@@ -691,7 +691,8 @@ function shell_checkpatch
local cmd=$1
$cmd | scripts/checkpatch.pl -q --strict - || true
- if $cmd | grep '^\+.*\WBUG' > /dev/null; then
+ local bug_lines=$("$cmd" | grep -m 1 -B 1 '^\+.*\WBUG' | grep -c
'^[+-].*\WBUG')
+ if test "$bug_lines" -eq 1; then
warn_or_fail "New BUG macro added"
fi
$cmd | grep '^\+.*drm_i915_private_t' > /dev/null && echo "WARNING: New
drm_i915_private_t added" || true
Are we interested in this?
Yes. Sorry, I've updated these lines so you'll need to rebase, I'm
afraid.
I'd also be fine with comparing the results of $(grep -c '^\+.*\WBUG)
and $(grep -c '^\-.*\WBUG) and complaining if there are more +'s than
-'s. But your stricter version is fine too.
BR,
Jani.
The version above doesn't really avoid all the issues, though; for
example if the edited BUG spans multiple lines, or if the pattern
spotted (first added line containing a word beginning with BUG) is in a
comment or string, or what's actually happened is that some code has
been moved from before an existing BUG() to after or vice-versa, but
diff thinks you've deleted the old BUG() and added a new one :(
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915/dsi: add support for gpio elements on CHV
From: Yogesh Mohan Marimuthu
Add support for CHV gpio programming in DSI gpio elements.
[Rewritten by Jani, based on earlier work by Yogesh and Deepak.]
Signed-off-by: Yogesh Mohan Marimuthu
Signed-off-by: Deepak M
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 65 ++
1 file changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 040ec5d6a7ac..7ea588be3e15 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -77,6 +77,23 @@ static inline struct vbt_panel *to_vbt_panel(struct
drm_panel *panel)
#define VLV_FUNCTION_TO_PAD_REG(reg) ((reg) + 8)
+#define CHV_MAX_GPIO_NUM_N 72
+#define CHV_MAX_GPIO_NUM_SE99
+#define CHV_MAX_GPIO_NUM_SW197
+#define CHV_MIN_GPIO_NUM_SE73
+#define CHV_MIN_GPIO_NUM_SW100
+#define CHV_MIN_GPIO_NUM_E 198
+
+#define CHV_PAD_FMLY_BASE 0x4400
+#define CHV_PAD_FMLY_SIZE 0x400
+#define CHV_PAD_CFG_0_1_REG_SIZE 0x8
+#define CHV_PAD_CFG_REG_SIZE 0x4
+#define CHV_VBT_MAX_PINS_PER_FMLY 15
+
+#define CHV_GPIO_CFG_UNLOCK0x
+#define CHV_GPIO_CFG_HIZ 0x8100
+#define CHV_GPIO_CFG_TX_STATE_SHIFT1
+
struct gpio_table {
u16 function_reg;
bool init;
@@ -243,6 +260,52 @@ static void vlv_exec_gpio(struct drm_i915_private
*dev_priv,
mutex_unlock(&dev_priv->sb_lock);
}
+static void chv_exec_gpio(struct drm_i915_private *dev_priv,
+ u8 gpio_source, u8 gpio_index, u8 action)
+{
+ u16 function, pad;
+ u16 family_num;
+ u8 port;
+
+ if (dev_priv->vbt.dsi.seq_version >= 3) {
+ if (gpio_index <= CHV_MAX_GPIO_NUM_N) {
+ port = CHV_IOSF_PORT_GPIO_N;
+ } else if (gpio_index <= CHV_MAX_GPIO_NUM_SE) {
+ port = CHV_IOSF_PORT_GPIO_SE;
+ gpio_index = gpio_index - CHV_MIN_GPIO_NUM_SE;
+ } else if (gpio_index <= CHV_MAX_GPIO_NUM_SW) {
+ port = CHV_IOSF_PORT_GPIO_SW;
+ gpio_index = gpio_index - CHV_MIN_GPIO_NUM_SW;
+ } else {
+ port = CHV_IOSF_PORT_GPIO_E;
+ gpio_index = gpio_index - CHV_MIN_GPIO_NUM_E;
+ }
+ } else if (dev_priv->vbt.dsi.seq_version == 2) {
+ if (gpio_source == 0) {
+ port = IOSF_PORT_GPIO_NC;
+ } else if (gpio_source == 1) {
+ port = IOSF_PORT_GPIO_SC;
+ } else {
+ DRM_DEBUG_KMS("unknown gpio source %u\n", gpio_source);
+ return;
+ }
+ } else {
+ port = IOSF_PORT_GPIO_NC;
+ }
+
+ family_num = gpio_index / CHV_VBT_MAX_PINS_PER_FMLY;
+ gpio_index = gpio_index - (family_num * CHV_VBT_MAX_PINS_PER_FMLY);
+ pad = CHV_PAD_FMLY_BASE + (family_num * CHV_PAD_FMLY_SIZE) +
+ (((u16)gpio_index) * CHV_PAD_CFG_0_1_REG_SIZE);
+ function = pad + CHV_PAD_CFG_REG_SIZE;
+
+ mutex_lock(&dev_priv->sb_lock);
+ vlv_iosf_sb_write(dev_priv, port, function, CHV_GPIO_CFG_UNLOCK);
+ vlv_iosf_sb_write(dev_priv, port, pad, CHV_GPIO_CFG_HIZ |
+ (action << CHV_GPIO_CFG_TX_STATE_SHIFT));
+ mutex_unlock(&dev_priv->sb_lock);
+}
+
static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
{
struct drm_device *dev = intel_dsi->base.base.dev;
@@ -262,6 +325,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
*intel_dsi, const u8 *data)
if (IS_VALLEYVIEW(dev_priv))
vlv_exec_gpio(dev_priv, gpio_source, gpio_index, action);
+ else if (IS_CHERRYVIEW(dev_priv))
+ chv_exec_gpio(dev_priv, gpio_source, gpio_index, action);
else
DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 07/10] drm/i915: abstract get config for cpu transcoder
On Wed, 16 Mar 2016, Ville Syrjälä wrote:
> [ text/plain ]
> On Tue, Mar 15, 2016 at 09:51:15PM +0200, Jani Nikula wrote:
>> Makes it neater to add the same for DSI transcoder. No functional
>> changes.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 83
>>
>> 1 file changed, 47 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index e485c1f9ca2b..842467528892 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -9893,6 +9893,49 @@ static void haswell_get_ddi_pll(struct
>> drm_i915_private *dev_priv,
>> pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
>> }
>>
>> +static bool hsw_get_trans_config(struct intel_crtc *crtc,
>> + struct intel_crtc_state *pipe_config,
>> + unsigned long *power_domain_mask)
>> +{
>
> To be consistent with existing practices we should probably call this
> ..._get_hw_state, or maybe ..._get_transcoder_state (if we want to
> follow the get_ddi_port_state() below).
>
>> +struct drm_device *dev = crtc->base.dev;
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +enum intel_display_power_domain power_domain;
>> +u32 tmp;
>> +
>> +pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
>> +
>> +tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
>> +if (tmp & TRANS_DDI_FUNC_ENABLE) {
>
> I guess as a followup we should do the
> intel_display_power_get_if_enabled() for the edp transcoder already
> before this read. Just need to be careful that we don't grab it twice
> then.
I checked this while writing the code, and IIUC
TRANS_DDI_FUNC_CTL(TRANSCODER_EDP) is in always on power.
BR,
Jani.
>
>> +enum pipe trans_edp_pipe;
>> +switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
>> +default:
>> +WARN(1, "unknown pipe linked to edp transcoder\n");
>> +case TRANS_DDI_EDP_INPUT_A_ONOFF:
>> +case TRANS_DDI_EDP_INPUT_A_ON:
>> +trans_edp_pipe = PIPE_A;
>> +break;
>> +case TRANS_DDI_EDP_INPUT_B_ONOFF:
>> +trans_edp_pipe = PIPE_B;
>> +break;
>> +case TRANS_DDI_EDP_INPUT_C_ONOFF:
>> +trans_edp_pipe = PIPE_C;
>> +break;
>> +}
>> +
>> +if (trans_edp_pipe == crtc->pipe)
>> +pipe_config->cpu_transcoder = TRANSCODER_EDP;
>> +}
>> +
>> +power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
>> +if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
>> +return false;
>> +*power_domain_mask |= BIT(power_domain);
>> +
>> +tmp = I915_READ(PIPECONF(pipe_config->cpu_transcoder));
>> +
>> +return tmp & PIPECONF_ENABLE;
>> +}
>> +
>> static void haswell_get_ddi_port_state(struct intel_crtc *crtc,
>> struct intel_crtc_state *pipe_config)
>> {
>> @@ -9943,48 +9986,18 @@ static bool haswell_get_pipe_config(struct
>> intel_crtc *crtc,
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> enum intel_display_power_domain power_domain;
>> unsigned long power_domain_mask;
>> -uint32_t tmp;
>> -bool ret;
>> +bool active;
>>
>> power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
>> if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
>> return false;
>> power_domain_mask = BIT(power_domain);
>>
>> -ret = false;
>> -
>> -pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
>> pipe_config->shared_dpll = NULL;
>>
>> -tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
>> -if (tmp & TRANS_DDI_FUNC_ENABLE) {
>> -enum pipe trans_edp_pipe;
>> -switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
>> -default:
>> -WARN(1, "unknown pipe linked to edp transcoder\n");
>> -case TRANS_DDI_EDP_INPUT_A_ONOFF:
>> -case TRANS_DDI_EDP_INPUT_A_ON:
>> -trans_edp_pipe = PIPE_A;
>> -break;
>> -case TRANS_DDI_EDP_INPUT_B_ONOFF:
>> -trans_edp_pipe = PIPE_B;
>> -break;
>> -case TRANS_DDI_EDP_INPUT_C_ONOFF:
>> -trans_edp_pipe = PIPE_C;
>> -break;
>> -}
>> -
>> -if (trans_edp_pipe == crtc->pipe)
>> -pipe_config->cpu_transcoder = TRANSCODER_EDP;
>> -}
>> -
>> -power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
>> -if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
>> -goto out;
>> -power_domain_mask |= BIT(power_domain);
>> +active = hsw_get_trans_c
Re: [Intel-gfx] [PATCH v6] igt/gem_trtt: Exercise the TRTT hardware
On 3/18/2016 2:52 PM, Chris Wilson wrote:
On Fri, Mar 18, 2016 at 02:31:23PM +0530, Goel, Akash wrote:
On 3/18/2016 2:06 PM, Chris Wilson wrote:
On Fri, Mar 18, 2016 at 02:07:40PM +0530, akash.g...@intel.com wrote:
+/* emit_store_qword
+ * populate batch buffer with MI_STORE_DWORD_IMM command
+ * @fd: drm file descriptor
+ * @cmd_buf: batch buffer
+ * @dw_offset: write offset in batch buffer
+ * @vaddr: destination Virtual address
+ * @data: u64 data to be stored at destination
+ */
+static int emit_store_qword(int fd, uint32_t *cmd_buf, uint32_t dw_offset,
+ uint64_t vaddr, uint64_t data)
+{
+ /* Check that softpin addresses are in the correct form */
+ igt_assert_eq_u64(vaddr, igt_canonical_addr(vaddr));
+
+ /* SDI cannot write to unaligned addresses */
+ igt_assert((vaddr & 3) == 0);
If I remember correctly a qword write from SDI must be 8 byte aligned.
Right?
Yes right. Sorry, my bad..
+
+ cmd_buf[dw_offset++] = MI_STORE_DWORD_IMM | 0x3;
+ cmd_buf[dw_offset++] = (uint32_t)vaddr;
+ cmd_buf[dw_offset++] = (uint32_t)(vaddr >> 32);
+ cmd_buf[dw_offset++] = data;
+ cmd_buf[dw_offset++] = data >> 32;
+
+ return dw_offset;
+}
Hopefully final comments!
Missed EINTR handling during evict, If you repeat the busy/hang tests
within the igt_fork_signal_helper(); igt_stop_signal_helper() that
should cover catching an inopportune signal.
Fine will add, thanks for suggesting this
So the signal will interrupt the Driver, which would be waiting for
the vma unbind to complete, from the eviction path.
Right, and we will report the error back to userspace as EINTR and
userspace will restart the syscall and we expect it to succeed
(eventually). Just useful for flushing out the error handling.
Having just remembered how useful this might be, I just extended
gem_softpin for similar reasons:
+ igt_subtest("evict-active-interruptible") {
+ struct timespec start = {};
+ while (igt_seconds_elapsed(&start) < 20)
+ test_evict_active(fd);
+ }
Thanks I just tested the interruptible versions like this :-
+ igt_fork_signal_helper();
+ igt_subtest("evict_active-interruptible")
+test_evict_active();
+
+ igt_subtest("evict_hang-interruptible")
+ test_evict_hang();
+ igt_stop_signal_helper();
Actually the hanging object test implicitly exercises the interruption
case (otherwise the test won't pass), error recovery as a part of GPU
reset wakes up/interrupts the waiters.
Best regards
Akash
-Chris
___
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: Get rid of intel_dp_dpcd_read_wake()
On Thu, Mar 17, 2016 at 07:56:33PM +0200, Jani Nikula wrote:
> On Thu, 17 Mar 2016, Lyude wrote:
> > Since we've fixed up drm_dp_dpcd_read() to allow for retries when things
> > timeout, there's no use for having this function anymore. Good riddens.
> >
> > Signed-off-by: Lyude
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 79
> > -
> > 1 file changed, 22 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index cdc2c15..fb4cbbe5 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3190,47 +3190,14 @@ static void chv_dp_post_pll_disable(struct
> > intel_encoder *encoder)
> > }
> >
> > /*
> > - * Native read with retry for link status and receiver capability reads for
> > - * cases where the sink may still be asleep.
> > - *
> > - * Sinks are *supposed* to come up within 1ms from an off state, but we're
> > also
> > - * supposed to retry 3 times per the spec.
> > - */
> > -static ssize_t
> > -intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
> > - void *buffer, size_t size)
> > -{
> > - ssize_t ret;
> > - int i;
> > -
> > - /*
> > -* Sometime we just get the same incorrect byte repeated
> > -* over the entire buffer. Doing just one throw away read
> > -* initially seems to "solve" it.
> > -*/
> > - drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
>
> Last time around I dug out the commit adding the line above, which fixed
> a bug, and said it should be accounted for somehow. But I've had a
> change of heart. I want this function gone already. We've improved the
> dp helpers considerably, and if this regresses, we need to look at
> fixing this either at the drm level or in our ->transfer hook.
>
> Acked-by: Jani Nikula
Hm, my idea was actually to 1:1 move intel_dp_dpcd_read_wake logic into
drm_dp_dpcd_read, without any functional change for i915.ko. And everyone
else shouldn't complain about a few more retries either.
That would also address Ville's grumpy nack.
-Daniel
>
>
> > -
> > - for (i = 0; i < 3; i++) {
> > - ret = drm_dp_dpcd_read(aux, offset, buffer, size);
> > - if (ret == size)
> > - return ret;
> > - msleep(1);
> > - }
> > -
> > - return ret;
> > -}
> > -
> > -/*
> > * Fetch AUX CH registers 0x202 - 0x207 which contain
> > * link status information
> > */
> > bool
> > intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
> > link_status[DP_LINK_STATUS_SIZE])
> > {
> > - return intel_dp_dpcd_read_wake(&intel_dp->aux,
> > - DP_LANE0_1_STATUS,
> > - link_status,
> > - DP_LINK_STATUS_SIZE) ==
> > DP_LINK_STATUS_SIZE;
> > + return drm_dp_dpcd_read(&intel_dp->aux, DP_LANE0_1_STATUS, link_status,
> > + DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
> > }
> >
> > /* These are source-specific values. */
> > @@ -3865,8 +3832,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > uint8_t rev;
> >
> > - if (intel_dp_dpcd_read_wake(&intel_dp->aux, 0x000, intel_dp->dpcd,
> > - sizeof(intel_dp->dpcd)) < 0)
> > + if (drm_dp_dpcd_read(&intel_dp->aux, 0x000, intel_dp->dpcd,
> > +sizeof(intel_dp->dpcd)) < 0)
> > return false; /* aux transfer failed */
> >
> > DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd),
> > intel_dp->dpcd);
> > @@ -3877,9 +3844,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > /* Check if the panel supports PSR */
> > memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
> > if (is_edp(intel_dp)) {
> > - intel_dp_dpcd_read_wake(&intel_dp->aux, DP_PSR_SUPPORT,
> > - intel_dp->psr_dpcd,
> > - sizeof(intel_dp->psr_dpcd));
> > + drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT,
> > +intel_dp->psr_dpcd,
> > +sizeof(intel_dp->psr_dpcd));
> > if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > dev_priv->psr.sink_support = true;
> > DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > @@ -3890,9 +3857,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> > uint8_t frame_sync_cap;
> >
> > dev_priv->psr.sink_support = true;
> > - intel_dp_dpcd_read_wake(&intel_dp->aux,
> > - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> > - &frame_sync_cap, 1);
> > + drm_dp_dpcd_read(&intel_dp->aux,
> > +DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> > +
Re: [Intel-gfx] [PATCH] drm/i915/kbl: Adding missing IS_KABYLAKE checks.
On Wed, 16 Mar 2016, Michel Thierry wrote: > [ text/plain ] > On 2/29/2016 2:35 PM, Jani Nikula wrote: >> On Fri, 26 Feb 2016, Rodrigo Vivi wrote: >>> Hi Jani and Daniel, >>> >>> I believe I forgot to cc:stable on this one and this is missing on >>> most branches out there including Linus 4.5-r5. >>> Is there any chance to get this patch in for 4.5? without this i915 is >>> not working on KBL. >> >> Is the referenced commit by Michel also required? >> >> Michel had found the main error first and his >> fix had better details on the history and got >> merged already: >> >> commit 16fbc291cb87c7defcd13ad715d3e4af0d523e43 >> Author: Michel Thierry >> Date: Wed Jan 6 12:08:36 2016 + >> >> drm/i915/kbl: Enable PW1 and Misc I/O power wells >> >> If that's needed, what else is needed? Where does the rabbit hole end? >> >>> Good thing is that this platform is still protected by >>> preliminary_hw_support. >> >> We do not backport cc: stable fixes for platforms that only have >> preliminary hw support. >> >> v4.5 is not released yet, and although towards the later -rc's the rules >> are pretty much the same as for stable kernels, I might consider >> cherry-picking kbl fixes that make platform enabling or early adoption >> easier. >> > > Hi Jani, > > Now that v4.5 has been released, would you consider _backporting_ these > two patches to allow kbl to boot? As I said we do not backport cc: stable fixes for platforms that only have preliminary hw support. We can discuss the rules we make for ourselves, but that discussion shouldn't be linked to specific patches. So I might have cherry-picked them through fixes *before* v4.5 was released, but there was no response to my mail... communication fail from my part I guess, but I kind of expected opinions. "I might consider" does not mean "I am going to". (Technically, *I* don't do stable backports. Also, the commits have to be in Linus' tree before they can be backported to stable. See Documentation/stable_kernel_rules.txt.) BR, Jani. > > AFAIK, these are the only patches needed, > drm/i915/kbl: Enable PW1 and Misc I/O power wells > [https://cgit.freedesktop.org/drm-intel/commit/?id=16fbc291cb87c7defcd13ad715d3e4af0d523e43] > and > drm/i915/kbl: Adding missing IS_KABYLAKE checks > [https://cgit.freedesktop.org/drm-intel/commit/?id=8d7a1c4a579c4ecfe360044c24dc1fbf97096752] > > Thanks, > > -Michel > >> BR, >> Jani. >> >> > -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Set GPU freq to idle_freq initially
On Wed, Mar 16, 2016 at 07:56:58PM +0200, Imre Deak wrote: > On Fri, 2016-03-04 at 21:43 +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Currently we set the initial GPU frequency to min_freq_softlimit > > on gen9, and to efficient_freq on VLV/CHV. On all the other platforms > > we set it to idle_freq. Let's use idle_freq across the board to make > > sure we don't waste power. This is especially relevant for VLV since > > Vnn won't drop to minimum unless the GPU is at the minimum frequency. > > > > Signed-off-by: Ville Syrjälä > > Yes, I think having the same logic on all platforms make sense, so: > Reviewed-by: Imre Deak > > I noticed that rps.min_freq is always the same as rps.idle_freq, what's > the reason to have both, could we remove one of them? Adding Chris. They have two different meanings, one is the hardware minimum and the other is the frequency to use at idle. As indicated by vlv, it was not always clear if the HW engineers thought it was a good idea to rest at minimum and so having a separate control knob would be useful. -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 05/10] drm/i915: Support for creating Stolen memory backed objects
From: Ankitprasad Sharma
Extend the drm_i915_gem_create structure to add support for
creating Stolen memory backed objects. Added a new flag through
which user can specify the preference to allocate the object from
stolen memory, which if set, an attempt will be made to allocate
the object from stolen memory subject to the availability of
free space in the stolen region.
v2: Rebased to the latest drm-intel-nightly (Ankit)
v3: Changed versioning of GEM_CREATE param, added new comments (Tvrtko)
v4: Changed size from 32b to 64b to prevent userspace overflow (Tvrtko)
Corrected function arguments ordering (Chris)
v5: Corrected function name (Chris)
v6: Updated datatype for flags to keep sizeof(drm_i915_gem_create) u64
aligned (Chris)
v7: Use first 8 bits of gem_create flags for placement (Chris), Add helper
function for object allocation from stolen region (Ankit)
v8: Added comment explaining STOLEN placement flag (Chris)
Testcase: igt/gem_stolen
Signed-off-by: Ankitprasad Sharma
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c| 3 +++
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 45 +++---
drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +--
include/uapi/drm/i915_drm.h| 41 +++
5 files changed, 89 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 85b3130..2ae460e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -172,6 +172,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_SOFTPIN:
value = 1;
break;
+ case I915_PARAM_CREATE_VERSION:
+ value = 2;
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fc21b52..ea87a89 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3259,7 +3259,7 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*dev_priv,
int i915_gem_init_stolen(struct drm_device *dev);
void i915_gem_cleanup_stolen(struct drm_device *dev);
struct drm_i915_gem_object *
-i915_gem_object_create_stolen(struct drm_device *dev, u32 size);
+i915_gem_object_create_stolen(struct drm_device *dev, u64 size);
struct drm_i915_gem_object *
i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
u32 stolen_offset,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a0116e8..43aacb1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -389,10 +389,36 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj)
kmem_cache_free(dev_priv->objects, obj);
}
+static struct drm_i915_gem_object *
+i915_gem_alloc_object_stolen(struct drm_device *dev, size_t size)
+{
+ struct drm_i915_gem_object *obj;
+ int ret;
+
+ mutex_lock(&dev->struct_mutex);
+ obj = i915_gem_object_create_stolen(dev, size);
+ if (!obj) {
+ mutex_unlock(&dev->struct_mutex);
+ return NULL;
+ }
+
+ /* Always clear fresh buffers before handing to userspace */
+ ret = i915_gem_object_clear(obj);
+ if (ret) {
+ drm_gem_object_unreference(&obj->base);
+ mutex_unlock(&dev->struct_mutex);
+ return NULL;
+ }
+
+ mutex_unlock(&dev->struct_mutex);
+ return obj;
+}
+
static int
i915_gem_create(struct drm_file *file,
struct drm_device *dev,
uint64_t size,
+ uint64_t flags,
uint32_t *handle_p)
{
struct drm_i915_gem_object *obj;
@@ -403,8 +429,21 @@ i915_gem_create(struct drm_file *file,
if (size == 0)
return -EINVAL;
+ if (flags & __I915_CREATE_UNKNOWN_FLAGS)
+ return -EINVAL;
+
/* Allocate the new object */
- obj = i915_gem_alloc_object(dev, size);
+ switch (flags & I915_CREATE_PLACEMENT_MASK) {
+ case I915_CREATE_PLACEMENT_NORMAL:
+ obj = i915_gem_alloc_object(dev, size);
+ break;
+ case I915_CREATE_PLACEMENT_STOLEN:
+ obj = i915_gem_alloc_object_stolen(dev, size);
+ break;
+ default:
+ return -EINVAL;
+ }
+
if (obj == NULL)
return -ENOMEM;
@@ -427,7 +466,7 @@ i915_gem_dumb_create(struct drm_file *file,
args->pitch = ALIGN(args->width * DIV_ROUND_UP(args->bpp, 8), 64);
args->size = args->pitch * args->height;
return i915_gem_create(file, dev,
- args->size, &args->handle);
+ args->size, 0, &args->handle);
Re: [Intel-gfx] [PATCH] drm/i915: simplify bind_to_vm init code
On Fri, Mar 18, 2016 at 11:10:50AM +, Tvrtko Ursulin wrote:
>
>
> On 18/03/16 10:46, Matthew Auld wrote:
> >No functional change, just makes the code easier to follow.
> >
> >v2:
> > - Remove local fence_size variable
> >(Tvrtko Ursulin)
> > - Remove redundant NULL ggtt_view check
> > - Reuse size variable
> >
> >Signed-off-by: Matthew Auld
> >---
> > drivers/gpu/drm/i915/i915_gem.c | 51
> > +++--
> > 1 file changed, 14 insertions(+), 37 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index f45856d..e5d9d0b 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -3468,50 +3468,27 @@ i915_gem_object_bind_to_vm(struct
> >drm_i915_gem_object *obj,
> > u32 fence_alignment, unfenced_alignment;
> > u32 search_flag, alloc_flag;
> > u64 start, end;
> >-u64 size, fence_size;
> >+u64 size;
> > struct i915_vma *vma;
> > int ret;
> >
> >-if (i915_is_ggtt(vm)) {
> >-u32 view_size;
> >-
> >-if (WARN_ON(!ggtt_view))
> >-return ERR_PTR(-EINVAL);
> >-
> >-view_size = i915_ggtt_view_size(obj, ggtt_view);
> >-
> >-fence_size = i915_gem_get_gtt_size(dev,
> >- view_size,
> >- obj->tiling_mode);
> >-fence_alignment = i915_gem_get_gtt_alignment(dev,
> >- view_size,
> >- obj->tiling_mode,
> >- true);
> >-unfenced_alignment = i915_gem_get_gtt_alignment(dev,
> >-view_size,
> >-
> >obj->tiling_mode,
> >-false);
> >-size = flags & PIN_MAPPABLE ? fence_size : view_size;
> >-} else {
> >-fence_size = i915_gem_get_gtt_size(dev,
> >- obj->base.size,
> >- obj->tiling_mode);
> >-fence_alignment = i915_gem_get_gtt_alignment(dev,
> >- obj->base.size,
> >- obj->tiling_mode,
> >- true);
> >-unfenced_alignment =
> >-i915_gem_get_gtt_alignment(dev,
> >- obj->base.size,
> >- obj->tiling_mode,
> >- false);
> >-size = flags & PIN_MAPPABLE ? fence_size : obj->base.size;
> >-}
> >+if (i915_is_ggtt(vm))
> >+size = i915_ggtt_view_size(obj, ggtt_view);
> >+else
> >+size = obj->base.size;
> >+
> >+fence_alignment = i915_gem_get_gtt_alignment(dev, size,
> >+ obj->tiling_mode, true);
> >+unfenced_alignment = i915_gem_get_gtt_alignment(dev, size,
> >+obj->tiling_mode,
> >+false);
> >
> > start = flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
> > end = vm->total;
> >-if (flags & PIN_MAPPABLE)
> >+if (flags & PIN_MAPPABLE) {
> > end = min_t(u64, end, dev_priv->gtt.mappable_end);
> >+size = i915_gem_get_gtt_size(dev, size, obj->tiling_mode);
No. Keep the start, end computation separate.
For example the above size needs only be done when inspecting the
i915_is_ggtt().
If you simplified the alignement as well, it becomes clearer. If you
reviewed the patches to handle vma, it would help. The key question is
what igt did you run to verify the changes?
-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 i-g-t 1/6] lib: kms: add crtc_id to igt_pipe_t
Signed-off-by: Lionel Landwerlin
---
lib/igt_kms.c | 1 +
lib/igt_kms.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f9a7bb0..515ffd0 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1213,6 +1213,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
int p = IGT_PLANE_2;
int j, type;
+ pipe->crtc_id = resources->crtcs[i];
pipe->display = display;
pipe->pipe = i;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 342db51..0a2d1b6 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -256,6 +256,7 @@ struct igt_pipe {
uint64_t background; /* Background color MSB BGR 16bpc LSB */
uint32_t background_changed : 1;
uint32_t background_property;
+ uint32_t crtc_id;
};
typedef struct {
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson
Cc: Tiago Vignatti
Cc: Stéphane Marchesin
Cc: David Herrmann
Cc: Sumit Semwal
Cc: Daniel Vetter
CC: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: intel-gfx@lists.freedesktop.org
Cc: de...@driverdev.osuosl.org
---
drivers/dma-buf/dma-buf.c | 17 +++--
drivers/gpu/drm/i915/i915_gem_dmabuf.c| 15 +--
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 5 +++--
drivers/gpu/drm/udl/udl_fb.c | 4 ++--
drivers/staging/android/ion/ion.c | 6 --
include/linux/dma-buf.h | 6 +++---
6 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 9810d1df0691..774a60f4309a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file,
struct dma_buf *dmabuf;
struct dma_buf_sync sync;
enum dma_data_direction direction;
+ int ret;
dmabuf = file->private_data;
@@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file,
}
if (sync.flags & DMA_BUF_SYNC_END)
- dma_buf_end_cpu_access(dmabuf, direction);
+ ret = dma_buf_end_cpu_access(dmabuf, direction);
else
- dma_buf_begin_cpu_access(dmabuf, direction);
+ ret = dma_buf_begin_cpu_access(dmabuf, direction);
- return 0;
+ return ret;
default:
return -ENOTTY;
}
@@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
*
* This call must always succeed.
*/
-void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
- enum dma_data_direction direction)
+int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
+ enum dma_data_direction direction)
{
+ int ret = 0;
+
WARN_ON(!dmabuf);
if (dmabuf->ops->end_cpu_access)
- dmabuf->ops->end_cpu_access(dmabuf, direction);
+ ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 1f3eef6fb345..0506016e18e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -228,25 +228,20 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
return ret;
}
-static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
dma_data_direction direction)
+static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
dma_data_direction direction)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_device *dev = obj->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- bool was_interruptible;
int ret;
- mutex_lock(&dev->struct_mutex);
- was_interruptible = dev_priv->mm.interruptible;
- dev_priv->mm.interruptible = false;
+ ret = i915_mutex_lock_interruptible(dev);
+ if (ret)
+ return ret;
ret = i915_gem_object_set_to_gtt_domain(obj, false);
-
- dev_priv->mm.interruptible = was_interruptible;
mutex_unlock(&dev->struct_mutex);
- if (unlikely(ret))
- DRM_ERROR("unable to flush buffer following CPU access;
rendering may be corrupt\n");
+ return ret;
}
static const struct dma_buf_ops i915_dmabuf_ops = {
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 3cf8aab23a39..af267c35d813 100644
--- a/drivers/gpu/drm/omap
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)
On Thu, 17 Mar 2016 08:57:23 +0100, Tomi Sarvela wrote: > > On Wednesday 16 March 2016 16:40:24 Takashi Iwai wrote: > > On Wed, 16 Mar 2016 16:37:06 +0100, Daniel Vetter wrote: > > > On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote: > > > > > > > > SND is recurring problem. I'd like to see drm-intel-nightly not breaking > > > > when pulling sound updates. > > > > > > We need to escalate this again, snd team seriously sucks at quality > > > control :( Adding Libin&Takashi. If this doesn't improve I need to throw > > > sound trees out of -nightly for real. > > > > Sorry about that, but I couldn't get the warning on my machine. > > > > How is the procedure to reproduce the bug? Please give the exact > > commit id and environment you're testing, too. > > Our CI has been built to mimic user environment, so base is up-to-date Ubuntu > 15.04. This affects to boot-up mechanics and usermode software versions. > There > are about dozen machines, 8 gens, from ILK to SKL. > > Reproduction: CI is doing these steps > > - Compile kernel: CI_DRM is drm-intel-nightly HEAD > - Deploy it to testhost: copy to /boot, recreate initrd > - Boot testhost to init 3 > - Run newest IGT/piglit with basic testset > - Collect results > > The last commits tested are: > > CI_DRM_1140 git://anongit.freedesktop.org/drm-intel > 3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 > > CI_DRM_1141 git://anongit.freedesktop.org/drm-intel > fc881ebd9c3c26919c7d1113f8bf7014e1a05563 > > CI_DRM_1142 git://anongit.freedesktop.org/drm-intel > 9f8709ffd099e85e5e116ed7d09f1b8009f40847 > > CI_DRM_1143 git://anongit.freedesktop.org/drm-intel > 5356c22379fc96cb087ee59bfdbbe46ec3bdf654 > > CI_DRM_1144 git://anongit.freedesktop.org/drm-intel > a5c43f5d1b4968a370f54bdda5387ce213aca785 > > CI_DRM_1145 git://anongit.freedesktop.org/drm-intel > bf3dcd53821a7d6c81f7061c6c7956aad57ec615 > > CI_DRM_1146 git://anongit.freedesktop.org/drm-intel > be0d1481fb1a2fd1cb199b81c9c01154a78d43dd > > CI_DRM_1147 git://anongit.freedesktop.org/drm-intel > dbbc6d276864d7b7a3a1edb04f0511153f9c3852 > > Note that drm-intel-nightly history changes, so the exact commits might not > be > there any more. Well, I have no internal access, so I have no idea which one succeeded and which one failed. Unfortunately I can't reproduce it in my side. A simpler unit test that can reliably reproduce the issue would be really appreciated... thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 19/19] drm/i915: Add fault injection support
On Wed, 2016-03-16 at 12:00 +, Chris Wilson wrote: > On Wed, Mar 16, 2016 at 01:39:08PM +0200, Imre Deak wrote: > > Add support for forcing an error at selected places in the driver. > > As an > > example add 4 options to fail during driver loading. > > > > Requested by Chris. > > > > v2: > > - Add fault point for modeset initialization > > - Print debug message when injecting an error > > v3: > > - Rename inject_fault to inject_load_failure, rename the related > > macros > > and helper accordingly (Chris) > > - Use a counter instead of a mask to identify the failure point > > (Daniel) > > - Mark the module option as _unsafe and keep i915_params ordered > > (Joonas) > > Now that you have something so simple to use, putting a failure point > at > the start and end of each init_func is trivial (to test the local > unwind > in each function as well as the global unwind). Ok can do this, but again preferably as a follow-up: i915_load_modeset_init() has pre-existing issues, the last thing I checked was some running work item that gets scheduled after we removed the module already (maybe the eDP VDD work). I'll track down that and try to clean up the rest of problems I see in i915_load_modeset_init(); with those I could add the additional checkpoints you suggest. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Tune down init error message due to failure injection
Atm, in case failure injection forces an error a subsequent error
messages will make automated tests (CI) report this event as a breakage,
even though the event is expected. To fix this print the error message
with debug log level in this case.
While at it print the error message for any init failure for
consistency.
CC: Chris Wilson
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_dma.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 68592b0..d107871 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -66,6 +66,14 @@ bool __i915_inject_load_failure(const char *func, int line)
return false;
}
+#define i915_load_error(fmt, ...) do { \
+ if (i915.inject_load_failure && \
+ i915_load_fail_count == i915.inject_load_failure) \
+ DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__); \
+ else\
+ DRM_ERROR(fmt, ##__VA_ARGS__); \
+} while(0)
+
static int i915_getparam(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
@@ -1332,10 +1340,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
}
ret = i915_load_modeset_init(dev);
- if (ret < 0) {
- DRM_ERROR("failed to init modeset\n");
+ if (ret < 0)
goto out_cleanup_vblank;
- }
i915_driver_register(dev_priv);
@@ -1357,6 +1363,8 @@ out_runtime_pm_put:
out_free_priv:
kfree(dev_priv);
+ i915_load_error("device initialization failed (%d)\n", ret);
+
return ret;
}
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 05/10] drm/i915: split get/set pipe timings to pipe and transcoder parts
On Tue, Mar 15, 2016 at 09:51:13PM +0200, Jani Nikula wrote:
> Prep work for DSI transcoders. No functional changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 27 +++
> 1 file changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7977a818326d..4bfad0199232 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7648,11 +7648,10 @@ static void i8xx_compute_dpll(struct intel_crtc *crtc,
> crtc_state->dpll_hw_state.dpll = dpll;
> }
>
> -static void intel_set_pipe_timings(struct intel_crtc *intel_crtc)
> +static void intel_set_trans_timings(struct intel_crtc *intel_crtc)
> {
> struct drm_device *dev = intel_crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - enum pipe pipe = intel_crtc->pipe;
> enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
> const struct drm_display_mode *adjusted_mode =
> &intel_crtc->config->base.adjusted_mode;
> uint32_t crtc_vtotal, crtc_vblank_end;
> @@ -7699,6 +7698,16 @@ static void intel_set_pipe_timings(struct intel_crtc
> *intel_crtc)
> I915_WRITE(VSYNC(cpu_transcoder),
> (adjusted_mode->crtc_vsync_start - 1) |
> ((adjusted_mode->crtc_vsync_end - 1) << 16));
> +}
> +
> +static void intel_set_pipe_timings(struct intel_crtc *intel_crtc)
> +{
> + struct drm_device *dev = intel_crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + enum pipe pipe = intel_crtc->pipe;
> + enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
> +
> + intel_set_trans_timings(intel_crtc);
>
> /* Workaround: when the EDP input selection is B, the VTOTAL_B must be
>* programmed with the VTOTAL_EDP value. Same for VTOTAL_C. This is
You split seems to be in the wrong place, as in we just want to split
out the PIPESRC thing from the rest. I'd just call them
set_pipe_timings() and set_pipe_src_size(). And we'll need to call the
latter even with DSI.
> @@ -7716,8 +7725,8 @@ static void intel_set_pipe_timings(struct intel_crtc
> *intel_crtc)
> (intel_crtc->config->pipe_src_h - 1));
> }
>
> -static void intel_get_pipe_timings(struct intel_crtc *crtc,
> -struct intel_crtc_state *pipe_config)
> +static void intel_get_trans_timings(struct intel_crtc *crtc,
> + struct intel_crtc_state *pipe_config)
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -7749,6 +7758,16 @@ static void intel_get_pipe_timings(struct intel_crtc
> *crtc,
> pipe_config->base.adjusted_mode.crtc_vtotal += 1;
> pipe_config->base.adjusted_mode.crtc_vblank_end += 1;
> }
> +}
> +
> +static void intel_get_pipe_timings(struct intel_crtc *crtc,
> +struct intel_crtc_state *pipe_config)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + uint32_t tmp;
> +
> + intel_get_trans_timings(crtc, pipe_config);
>
> tmp = I915_READ(PIPESRC(crtc->pipe));
> pipe_config->pipe_src_h = (tmp & 0x) + 1;
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: simplify bind_to_vm init code
No functional change, just makes the code easier to follow.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 41 +++--
1 file changed, 11 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b854af2..5a8d69d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3470,46 +3470,27 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
u32 fence_alignment, unfenced_alignment;
u32 search_flag, alloc_flag;
u64 start, end;
- u64 size, fence_size;
+ u64 size, obj_size, fence_size;
struct i915_vma *vma;
int ret;
if (i915_is_ggtt(vm)) {
- u32 view_size;
-
if (WARN_ON(!ggtt_view))
return ERR_PTR(-EINVAL);
- view_size = i915_ggtt_view_size(obj, ggtt_view);
-
- fence_size = i915_gem_get_gtt_size(dev,
- view_size,
- obj->tiling_mode);
- fence_alignment = i915_gem_get_gtt_alignment(dev,
-view_size,
-obj->tiling_mode,
-true);
- unfenced_alignment = i915_gem_get_gtt_alignment(dev,
- view_size,
-
obj->tiling_mode,
- false);
- size = flags & PIN_MAPPABLE ? fence_size : view_size;
+ obj_size = i915_ggtt_view_size(obj, ggtt_view);
} else {
- fence_size = i915_gem_get_gtt_size(dev,
- obj->base.size,
- obj->tiling_mode);
- fence_alignment = i915_gem_get_gtt_alignment(dev,
-obj->base.size,
-obj->tiling_mode,
-true);
- unfenced_alignment =
- i915_gem_get_gtt_alignment(dev,
- obj->base.size,
- obj->tiling_mode,
- false);
- size = flags & PIN_MAPPABLE ? fence_size : obj->base.size;
+ obj_size = obj->base.size;
}
+ fence_size = i915_gem_get_gtt_size(dev, obj_size, obj->tiling_mode);
+ fence_alignment = i915_gem_get_gtt_alignment(dev, obj_size,
+obj->tiling_mode, true);
+ unfenced_alignment = i915_gem_get_gtt_alignment(dev, obj_size,
+ obj->tiling_mode,
+ false);
+ size = flags & PIN_MAPPABLE ? fence_size : obj_size;
+
start = flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
end = vm->total;
if (flags & PIN_MAPPABLE)
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 (rebased) 3/4] drm/i915: Move pll power state to crtc power domains.
On Mon, 2016-03-14 at 09:27 +0100, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 +++---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 4
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 17d07a729cc0..dd76df70c62a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5276,6 +5276,9 @@ static unsigned long get_crtc_power_domains(struct
> drm_crtc *crtc,
> mask |= BIT(intel_display_port_power_domain(intel_encoder));
> }
>
> + if (crtc_state->shared_dpll)
> + mask |= BIT(POWER_DOMAIN_PLLS);
> +
> return mask;
> }
>
> @@ -15729,9 +15732,6 @@ static void intel_modeset_readout_hw_state(struct
> drm_device *dev)
>
> DRM_DEBUG_KMS("%s hw state readout: crtc_mask 0x%08x, on
> %i\n",
> pll->name, pll->config.crtc_mask, pll->on);
> -
> - if (pll->config.crtc_mask)
> - intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
> }
>
> for_each_intel_encoder(dev, encoder) {
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 213862e8cd04..a9084c7c3a36 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -135,8 +135,6 @@ void intel_enable_shared_dpll(struct intel_crtc *crtc)
> }
> WARN_ON(pll->on);
>
> - intel_display_power_get(dev_priv, POWER_DOMAIN_PLLS);
> -
> DRM_DEBUG_KMS("enabling %s\n", pll->name);
> pll->funcs.enable(dev_priv, pll);
> pll->on = true;
> @@ -173,8 +171,6 @@ void intel_disable_shared_dpll(struct intel_crtc *crtc)
> DRM_DEBUG_KMS("disabling %s\n", pll->name);
> pll->funcs.disable(dev_priv, pll);
> pll->on = false;
> -
> - intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
> }
>
> static struct intel_shared_dpll *
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] dim: Avoid false positives with BUG detection
On Thu, 17 Mar 2016, Tvrtko Ursulin wrote:
> [ text/plain ]
>
>
> On 11/03/16 15:31, Tvrtko Ursulin wrote:
>> From: Tvrtko Ursulin
>>
>> Makes sure that the diff line adding the BUG is not immediately
>> preceded by the diff line removing the BUG. Or in other words,
>> avoids false positives when existing BUG is edited.
>>
>> v2: Sent the incomplete version out...
>>
>> Signed-off-by: Tvrtko Ursulin
>> ---
>> dim | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/dim b/dim
>> index 1e7622a1e902..5392c64bf5b4 100755
>> --- a/dim
>> +++ b/dim
>> @@ -691,7 +691,8 @@ function shell_checkpatch
>> local cmd=$1
>>
>> $cmd | scripts/checkpatch.pl -q --strict - || true
>> -if $cmd | grep '^\+.*\WBUG' > /dev/null; then
>> +local bug_lines=$("$cmd" | grep -m 1 -B 1 '^\+.*\WBUG' | grep -c
>> '^[+-].*\WBUG')
>> +if test "$bug_lines" -eq 1; then
>> warn_or_fail "New BUG macro added"
>> fi
>> $cmd | grep '^\+.*drm_i915_private_t' > /dev/null && echo "WARNING: New
>> drm_i915_private_t added" || true
>>
>
> Are we interested in this?
Yes. Sorry, I've updated these lines so you'll need to rebase, I'm
afraid.
I'd also be fine with comparing the results of $(grep -c '^\+.*\WBUG)
and $(grep -c '^\-.*\WBUG) and complaining if there are more +'s than
-'s. But your stricter version is fine too.
BR,
Jani.
>
> Regards,
>
> Tvrtko
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/10] drm/i915: Support for pread/pwrite from/to non shmem backed objects
From: Ankitprasad Sharma
This patch adds support for extending the pread/pwrite functionality
for objects not backed by shmem. The access will be made through
gtt interface. This will cover objects backed by stolen memory as well
as other non-shmem backed objects.
v2: Drop locks around slow_user_access, prefault the pages before
access (Chris)
v3: Rebased to the latest drm-intel-nightly (Ankit)
v4: Moved page base & offset calculations outside the copy loop,
corrected data types for size and offset variables, corrected if-else
braces format (Tvrtko/kerneldocs)
v5: Enabled pread/pwrite for all non-shmem backed objects including
without tiling restrictions (Ankit)
v6: Using pwrite_fast for non-shmem backed objects as well (Chris)
v7: Updated commit message, Renamed i915_gem_gtt_read to i915_gem_gtt_copy,
added pwrite slow path for non-shmem backed objects (Chris/Tvrtko)
v8: Updated v7 commit message, mutex unlock around pwrite slow path for
non-shmem backed objects (Tvrtko)
v9: Corrected check during pread_ioctl, to avoid shmem_pread being
called for non-shmem backed objects (Tvrtko)
v10: Moved the write_domain check to needs_clflush and tiling mode check
to pwrite_fast (Chris)
v11: Use pwrite_fast fallback for all objects (shmem and non-shmem backed),
call fast_user_write regardless of pagefault in previous iteration
v12: Use page-by-page copy for slow user access too (Chris)
v13: Handled EFAULT, Avoid use of WARN_ON, put_fence only if whole obj
pinned (Chris)
v14: Corrected datatypes/initializations (Tvrtko)
Testcase: igt/gem_stolen, igt/gem_pread, igt/gem_pwrite
Signed-off-by: Ankitprasad Sharma
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 221 ++--
1 file changed, 189 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9d47d0e..a627333 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -55,6 +55,9 @@ static bool cpu_cache_is_coherent(struct drm_device *dev,
static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
{
+ if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
+ return false;
+
if (!cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
return true;
@@ -646,6 +649,141 @@ shmem_pread_slow(struct page *page, int
shmem_page_offset, int page_length,
return ret ? - EFAULT : 0;
}
+static inline unsigned long
+slow_user_access(struct io_mapping *mapping,
+uint64_t page_base, int page_offset,
+char __user *user_data,
+unsigned long length, bool pwrite)
+{
+ void __iomem *ioaddr;
+ void *vaddr;
+ uint64_t unwritten;
+
+ ioaddr = io_mapping_map_wc(mapping, page_base);
+ /* We can use the cpu mem copy function because this is X86. */
+ vaddr = (void __force *)ioaddr + page_offset;
+ if (pwrite)
+ unwritten = __copy_from_user(vaddr, user_data, length);
+ else
+ unwritten = __copy_to_user(user_data, vaddr, length);
+
+ io_mapping_unmap(ioaddr);
+ return unwritten;
+}
+
+static int
+i915_gem_gtt_pread(struct drm_device *dev,
+ struct drm_i915_gem_object *obj, uint64_t size,
+ uint64_t data_offset, uint64_t data_ptr)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_mm_node node;
+ char __user *user_data;
+ uint64_t remain;
+ uint64_t offset;
+ int ret;
+
+ ret = i915_gem_obj_ggtt_pin(obj, 0, PIN_MAPPABLE);
+ if (ret) {
+ ret = insert_mappable_node(dev_priv, &node, PAGE_SIZE);
+ if (ret)
+ goto out;
+
+ ret = i915_gem_object_get_pages(obj);
+ if (ret) {
+ remove_mappable_node(&node);
+ goto out;
+ }
+
+ i915_gem_object_pin_pages(obj);
+ } else {
+ node.start = i915_gem_obj_ggtt_offset(obj);
+ node.allocated = false;
+ ret = i915_gem_object_put_fence(obj);
+ if (ret)
+ goto out_unpin;
+ }
+
+ ret = i915_gem_object_set_to_gtt_domain(obj, false);
+ if (ret)
+ goto out_unpin;
+
+ user_data = to_user_ptr(data_ptr);
+ remain = size;
+ offset = data_offset;
+
+ mutex_unlock(&dev->struct_mutex);
+ if (likely(!i915.prefault_disable)) {
+ ret = fault_in_multipages_writeable(user_data, remain);
+ if (ret) {
+ mutex_lock(&dev->struct_mutex);
+ goto out_unpin;
+ }
+ }
+
+ while (remain > 0) {
+ /* Operation in this page
+*
+* page_base = page offset within aperture
+* page_offset = offset within
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)
On Fri, 18 Mar 2016 09:12:53 +0100,
Tomi Sarvela wrote:
>
> On Friday 18 March 2016 09:00:13 Takashi Iwai wrote:
> > On Fri, 18 Mar 2016 08:36:27 +0100,
> >
> > Do you have the commit of the last working kernel?
> >
> > > The unit tests that hang quite reliably on first run are
> > > igt@gem_ringfill_basic-default-s3
> > > igt@drv_module_reload_basic
> > > igt@kms_pipe_crc_basic@suspend-read-crc-pipe-[abc]
> >
> > Where can I get these?
>
> IGT is intel-gpu-tools, hardware unittests using piglit as a base. CI runs
> BAT
> (Basic Acceptance Tests), a set of IGT tests: around 200 tests, runs under 10
> minutes. Can be run with ${IGT_PATH}/scripts/run-tests.sh -t basic
>
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
>
> http://anongit.freedesktop.org/git/piglit.git
>
> Latest working drm-intel commit was CI_DRM_1139:
> 3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 2016-03-14_09-06-45
> drm-intel-nightly:
> 2016y-03m-14d-09h-06m-00s UTC integration manifest
There were a few different kernel warnings, so this date is possibly a
red herring. One is the kernel warning from pin2port(), and this has
nothing to do with Skylake. It's being addressed now.
The problem I can't follow is the PM refcount unbalance found on
Skylake. It'd be helpful if you can give the exact *minimal*
reproducer. The warning shows the result, and it means that something
wrong did happen before that. So, we need the procedure until that
point, not the point of the outcome.
thanks,
Takashi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/6] drm/i915/bxt: allow dsi on any pipe
BXT isn't as limited as BYT and CHT regarding DSI pipes and ports. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dsi.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index dd6f7bc4f444..456676c00059 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -1198,8 +1198,13 @@ void intel_dsi_init(struct drm_device *dev) intel_connector->get_hw_state = intel_connector_get_hw_state; intel_connector->unregister = intel_connector_unregister; - /* Pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI port C */ - if (port == PORT_A) + /* +* On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI +* port C. BXT isn't limited like this. +*/ + if (IS_BROXTON(dev_priv)) + intel_encoder->crtc_mask = BIT(PIPE_A) | BIT(PIPE_B) | BIT(PIPE_C); + else if (port == PORT_A) intel_encoder->crtc_mask = BIT(PIPE_A); else intel_encoder->crtc_mask = BIT(PIPE_B); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection
On Thu, 2016-03-17 at 21:48 +, Chris Wilson wrote: > On Thu, Mar 17, 2016 at 11:10:42PM +0200, Imre Deak wrote: > > Well, I can follow-up on an export patch for that, but getting that > > merged may take a while, so could we go with the current version > > until > > that? > > What's the current version? ;) v3. Actually you were right, there is a reason why no dev_vprintk exists. It's because dev_printk provides that with %pV. So learned something new today and it wasn't a nuisance.. I'll use that then and a function instead of the macro. > For my tastes, I really want the "please file a bug" to be separate, > and I think KERN_NOTICE. Ok, I used KERN_INFO but will change that to KERN_NOTICE. > I would also like this to be the preferred > DRM_ERROR reporting mechanism i.e. anytime we emit an ERROR we should > be > encouraging the user to file a bug, and do so in a user friendly > fashion. Ok, but only in i915 I assume. Should we also convert then all DRM_ERROR to dev_err - with an *ERROR* prefix - or still use DRM_ERROR? --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Release power ref after updating wm
Matt has a similar fix already on the list, Matt/Ville what's the plan with that? Could we have a stop-gap solution? --Imre On Wed, 2016-03-16 at 17:11 +0200, Gabriel Feceoru wrote: > On HSW/BDW there are random dmesg-warn errors while running kms > tests, like: > > [90587.867077] Call Trace: > [90587.867085] [] dump_stack+0x67/0x99 > [90587.867094] [] warn_slowpath_common+0x81/0xc0 > [90587.867099] [] warn_slowpath_fmt+0x47/0x50 > [90587.867150] [] hsw_write32+0x280/0x290 [i915] > [90587.867186] [] _ilk_disable_lp_wm+0x98/0xd0 > [i915] > [90587.867222] [] > ilk_program_watermarks+0x4a2/0x940 [i915] > [90587.867260] [] > ilk_optimize_watermarks+0x50/0x70 [i915] > [90587.867311] [] intel_atomic_commit+0x742/0x2170 > [i915] > [90587.867319] [] ? wait_woken+0xa0/0xa0 > [90587.867326] [] drm_atomic_commit+0x32/0x50 > [90587.867333] [] > drm_atomic_helper_connector_dpms+0xe9/0x1a0 > [90587.867340] [] > drm_mode_obj_set_property_ioctl+0x21d/0x230 > [90587.867346] [] > drm_mode_connector_property_set_ioctl+0x2b/0x30 > [90587.867352] [] drm_ioctl+0x236/0x4f0 > [90587.867358] [] ? > drm_mode_obj_set_property_ioctl+0x230/0x230 > [90587.867366] [] do_vfs_ioctl+0x8e/0x680 > [90587.867372] [] ? __fget_light+0x6a/0x90 > [90587.867378] [] SyS_ioctl+0x3c/0x70 > [90587.867386] [] > entry_SYSCALL_64_fastpath+0x16/0x73 > > Since writing the watermarks requires MMIO access, this should be > done before > releasing the power reference. > > This clears the flip-flops in kms tests on HSW/BDW. > > Signed-off-by: Gabriel Feceoru > --- > drivers/gpu/drm/i915/intel_display.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index ce55f0b..b141e52 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -13631,9 +13631,6 @@ static int intel_atomic_commit(struct > drm_device *dev, > modeset_put_power_domains(dev_priv, > put_domains[i]); > } > > - if (intel_state->modeset) > - intel_display_power_put(dev_priv, > POWER_DOMAIN_MODESET); > - > /* > * Now that the vblank has passed, we can go ahead and > program the > * optimal watermarks on platforms that need two-step > watermark > @@ -13648,6 +13645,9 @@ static int intel_atomic_commit(struct > drm_device *dev, > dev_priv- > >display.optimize_watermarks(intel_cstate); > } > > + if (intel_state->modeset) > + intel_display_power_put(dev_priv, > POWER_DOMAIN_MODESET); > + > mutex_lock(&dev->struct_mutex); > drm_atomic_helper_cleanup_planes(dev, state); > mutex_unlock(&dev->struct_mutex); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restrict usage of live status check
On Thu, 17 Mar 2016, Shashank Sharma wrote:
> [ text/plain ]
> This patch restricts usage of live status check for HDMI detection.
> While testing certain (monitor + cable) combinations with various
> intel platforms, it seems that live status register is not reliable
> on some older devices. So limit the live_status check from VLV onwards.
>
> This fixes a regression introduced in:
> commit: 237ed86 "drm/i915: Check live status"
> Author: Sonika Jindal
> Date: Tue Sep 15 09:44:20 2015 +0530
>
Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid")
Cc: sta...@vger.kernel.org # v4.4
Bugzilla: ?
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e2dab48..d24d18a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> enum drm_connector_status status;
> struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> - bool live_status = false;
> + struct drm_device *dev = connector->dev;
This is unnecessary.
> + bool live_status = true;
> unsigned int try;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> @@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector,
> bool force)
>
> intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>
> - for (try = 0; !live_status && try < 9; try++) {
> - if (try)
> - msleep(10);
> - live_status = intel_digital_port_connected(dev_priv,
> + /*
> + * Live status check for HDMI detection is not very
> + * reliable on older platforms. So insist the live
> + * status check for EDID read from VLV onwards.
> + */
> + if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
Replace dev with dev_priv. Both work, it's magic, but we prefer using
dev_priv where possible.
Move try variable declaration here.
> + for (try = 0; !live_status && try < 9; try++) {
You'll now ignore live_status on all platforms. (But please do not turn
this into a do-while, keep it as a for loop.)
> + if (try)
> + msleep(10);
> + live_status = intel_digital_port_connected(dev_priv,
> hdmi_to_dig_port(intel_hdmi));
> + }
> + DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
Consider using onoff(live_status) instead of live_status ? "up" :
"down".
> }
>
> - if (!live_status)
> - DRM_DEBUG_KMS("Live status not up!");
> -
> intel_hdmi_unset_edid(connector);
>
> if (intel_hdmi_set_edid(connector, live_status)) {
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Restrict usage of live status check
On Fri, Mar 18, 2016 at 08:51:29AM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 3/17/2016 10:17 PM, Ville Syrjälä wrote:
> > On Thu, Mar 17, 2016 at 10:03:04PM +0530, Sharma, Shashank wrote:
> >> Hey Chris,
> >> I added comments for both Ville and you, please help me to understand this.
> >>
> >> Regards
> >> Shashank
> >>
> >> On 3/17/2016 9:51 PM, Ville Syrjälä wrote:
> >>> On Thu, Mar 17, 2016 at 09:35:30PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
>
> On 3/17/2016 9:31 PM, Ville Syrjälä wrote:
> > On Thu, Mar 17, 2016 at 09:15:39PM +0530, Sharma, Shashank wrote:
> >> Regards
> >> Shashank
> >>
> >> On 3/17/2016 6:34 PM, Ville Syrjälä wrote:
> >>> On Thu, Mar 17, 2016 at 01:29:25PM +0530, Shashank Sharma wrote:
> This patch restricts usage of live status check for HDMI detection.
> While testing certain (monitor + cable) combinations with various
> intel platforms, it seems that live status register is not reliable
> on some older devices. So limit the live_status check from VLV
> onwards.
>
> This fixes a regression introduced in:
> commit: 237ed86 "drm/i915: Check live status"
> Author: Sonika Jindal
> Date: Tue Sep 15 09:44:20 2015 +0530
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e2dab48..d24d18a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector
> *connector, bool force)
> enum drm_connector_status status;
> struct intel_hdmi *intel_hdmi =
> intel_attached_hdmi(connector);
> struct drm_i915_private *dev_priv =
> to_i915(connector->dev);
> -bool live_status = false;
> +struct drm_device *dev = connector->dev;
> +bool live_status = true;
> unsigned int try;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> @@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector
> *connector, bool force)
>
> intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>
> -for (try = 0; !live_status && try < 9; try++) {
> -if (try)
> -msleep(10);
> -live_status = intel_digital_port_connected(dev_priv,
> +/*
> +* Live status check for HDMI detection is not very
> +* reliable on older platforms. So insist the live
> +* status check for EDID read from VLV onwards.
> +*/
> +if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
> +for (try = 0; !live_status && try < 9; try++) {
> +if (try)
> +msleep(10);
> +live_status =
> intel_digital_port_connected(dev_priv,
> hdmi_to_dig_port(intel_hdmi));
> +}
> +DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" :
> "down");
> }
>
> -if (!live_status)
> -DRM_DEBUG_KMS("Live status not up!");
> -
> >>>
> >>> As I said before, I think this whole thing could be solved with a
> >>> simple
> >>> two-liner here:
> >>>
> >>> + if (...)
> >>> + live_status = true;
> >>>
> >> Yes I remember, and I replied on that already that why we would like to
> >> keep the live status check. In fact I would be ok to remove this check
> >> if you can suggest some other way of making this work for other
> >> operating systems/sw platforms.
> >
> > My two liner would keep the check.
> >
> Sorry, I might have not understood you properly.
> Do you mean:
> if (INTEL_INFO(dev)->gen < 7 && IS_IVYBRIDGE(dev)) {
> live_status = true;
> } else {
> do the same looping for retry;
> }
> >>>
> >>> No, I mean
> >>>
> >>> {
> >>> ...
> >>> do loop;
> >>>
> >>> if (!live_status)
> >>> DRM_DEBUG_KMS("Live status not up!");
> >>>
> >>> + if (don't trust live status)
> >>> + live_status = true;
> >>>
> >>> intel_hdmi_unset_edid();
> >>>
> >>> if (intel_hdmi_set_edid(live_status)) {
> >>> ...
> >>> }
> >>>
> >>>
> >> In fact, this is what I have done.
> >> If you see the
[Intel-gfx] [PATCH] drm/i915: simplify bind_to_vm init code
No functional change, just makes the code easier to follow.
v2:
- Remove local fence_size variable
(Tvrtko Ursulin)
- Remove redundant NULL ggtt_view check
- Reuse size variable
v3:
(Chris Wilson)
- Keep start, end computation separate
- Simplify alignment
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 52 +++--
1 file changed, 13 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f45856d..ffb802e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3465,48 +3465,23 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
{
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- u32 fence_alignment, unfenced_alignment;
+ u32 min_alignment;
u32 search_flag, alloc_flag;
u64 start, end;
- u64 size, fence_size;
+ u64 size;
struct i915_vma *vma;
int ret;
- if (i915_is_ggtt(vm)) {
- u32 view_size;
-
- if (WARN_ON(!ggtt_view))
- return ERR_PTR(-EINVAL);
-
- view_size = i915_ggtt_view_size(obj, ggtt_view);
-
- fence_size = i915_gem_get_gtt_size(dev,
- view_size,
- obj->tiling_mode);
- fence_alignment = i915_gem_get_gtt_alignment(dev,
-view_size,
-obj->tiling_mode,
-true);
- unfenced_alignment = i915_gem_get_gtt_alignment(dev,
- view_size,
-
obj->tiling_mode,
- false);
- size = flags & PIN_MAPPABLE ? fence_size : view_size;
- } else {
- fence_size = i915_gem_get_gtt_size(dev,
- obj->base.size,
- obj->tiling_mode);
- fence_alignment = i915_gem_get_gtt_alignment(dev,
-obj->base.size,
-obj->tiling_mode,
-true);
- unfenced_alignment =
- i915_gem_get_gtt_alignment(dev,
- obj->base.size,
+ if (i915_is_ggtt(vm))
+ size = i915_ggtt_view_size(obj, ggtt_view);
+ else
+ size = obj->base.size;
+
+ min_alignment = i915_gem_get_gtt_alignment(dev, size,
obj->tiling_mode,
- false);
- size = flags & PIN_MAPPABLE ? fence_size : obj->base.size;
- }
+ flags & PIN_MAPPABLE);
+ if (flags & PIN_MAPPABLE)
+ size = i915_gem_get_gtt_size(dev, size, obj->tiling_mode);
start = flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
end = vm->total;
@@ -3516,9 +3491,8 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
end = min_t(u64, end, (1ULL << 32) - PAGE_SIZE);
if (alignment == 0)
- alignment = flags & PIN_MAPPABLE ? fence_alignment :
- unfenced_alignment;
- if (flags & PIN_MAPPABLE && alignment & (fence_alignment - 1)) {
+ alignment = min_alignment;
+ if (flags & PIN_MAPPABLE && alignment & (min_alignment - 1)) {
DRM_DEBUG("Invalid object (view type=%u) alignment requested
%u\n",
ggtt_view ? ggtt_view->type : 0,
alignment);
--
2.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Name all intel_ringbuffer instances ring
On Thu, Mar 17, 2016 at 05:10:36PM +, Tvrtko Ursulin wrote:
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 3e40f7bf2147..ce7337b0aa14 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -159,7 +159,7 @@ struct intel_engine_cs {
> unsigned int guc_id;
> u32 mmio_base;
> struct drm_device *dev;
> - struct intel_ringbuffer *buffer;
> + struct intel_ringbuffer *ring;
> struct list_head buffers;
I was thinking this should be legacy_ring for distinctness. It only
actually gets referred to in a few places so shouldn't be too much of a
nuisance (and mostly it is via local intel_ring).
I did this in a few more steps trying to merge code as I went, but this
should reduce the churn I have in a nice mechanical fashion, so from
that perspective:
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: fix sparse warning for using false as NULL
drivers/gpu/drm/i915/intel_dpll_mgr.c:1200:32: warning: Using plain integer as
NULL pointer
Fixes: 304b65cbdc8d ("drm/i915: Move SKL/KLB pll selection logic to
intel_dpll_mgr.c")
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 74d5aecc0be5..e53d57c39056 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -1197,7 +1197,7 @@ skl_get_dpll(struct intel_crtc *crtc, struct
intel_crtc_state *crtc_state,
ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
if (!skl_ddi_calculate_wrpll(clock * 1000, &wrpll_params))
- return false;
+ return NULL;
cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] FW: [PATCH] drm/i915: Restrict usage of live status check
On Thu, 17 Mar 2016, "Sharma, Shashank" wrote:
> +intel-gfx
Please repost the patch to intel-gfx, just adding cc: makes the patch
painful to review and apply, and CI won't pick it up.
BR,
Jani.
>
> Regards
> Shashank
> -Original Message-
> From: Sharma, Shashank
> Sent: Thursday, March 17, 2016 9:37 AM
> To: Jindal, Sonika; Vetter, Daniel; ville.syrj...@linux.intel.com;
> jani.nik...@linux.intel.com
> Cc: Sharma, Shashank
> Subject: [PATCH] drm/i915: Restrict usage of live status check
>
> This patch restricts usage of live status check for HDMI detection.
> While testing certain (monitor + cable) combinations with various intel
> platforms, it seems that live status register is not reliable on some older
> devices. So limit the live_status check from VLV onwards.
>
> This fixes a regression introduced in:
> commit: 237ed86 "drm/i915: Check live status"
> Author: Sonika Jindal
> Date: Tue Sep 15 09:44:20 2015 +0530
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e2dab48..d24d18a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1397,7 +1397,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> enum drm_connector_status status;
> struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> - bool live_status = false;
> + struct drm_device *dev = connector->dev;
> + bool live_status = true;
> unsigned int try;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> @@ -1405,16 +1406,21 @@ intel_hdmi_detect(struct drm_connector *connector,
> bool force)
>
> intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>
> - for (try = 0; !live_status && try < 9; try++) {
> - if (try)
> - msleep(10);
> - live_status = intel_digital_port_connected(dev_priv,
> + /*
> + * Live status check for HDMI detection is not very
> + * reliable on older platforms. So insist the live
> + * status check for EDID read from VLV onwards.
> + */
> + if (INTEL_INFO(dev)->gen >= 7 && !IS_IVYBRIDGE(dev)) {
> + for (try = 0; !live_status && try < 9; try++) {
> + if (try)
> + msleep(10);
> + live_status = intel_digital_port_connected(dev_priv,
> hdmi_to_dig_port(intel_hdmi));
> + }
> + DRM_DEBUG_KMS("Live status %s\n", live_status ? "up" : "down");
> }
>
> - if (!live_status)
> - DRM_DEBUG_KMS("Live status not up!");
> -
> intel_hdmi_unset_edid(connector);
>
> if (intel_hdmi_set_edid(connector, live_status)) {
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Move CSB MMIO reads out of the execlists lock
On Thu, Mar 17, 2016 at 12:59:46PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> By reading the CSB (slow MMIO accesses) into a temporary local
> buffer we can decrease the duration of holding the execlist
> lock.
>
> Main advantage is that during heavy batch buffer submission we
> reduce the execlist lock contention, which should decrease the
> latency and CPU usage between the submitting userspace process
> and interrupt handling.
>
> Downside is that we need to grab and relase the forcewake twice,
> but as the below numbers will show this is completely hidden
> by the primary gains.
>
> Testing with "gem_latency -n 100" (submit batch buffers with a
> hundred nops each) shows more than doubling of the throughput
> and more than halving of the dispatch latency, overall latency
> and CPU time spend in the submitting process.
>
> Submitting empty batches ("gem_latency -n 0") does not seem
> significantly affected by this change with throughput and CPU
> time improving by half a percent, and overall latency worsening
> by the same amount.
>
> Above tests were done in a hundred runs on a big core Broadwell.
>
> v2:
> * Overflow protection to local CSB buffer.
> * Use closer dev_priv in execlists_submit_requests. (Chris Wilson)
>
> v3: Rebase.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 77
>
> 1 file changed, 38 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index f72782200226..c6b3a9d19af2 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -416,15 +416,23 @@ static void execlists_update_context(struct
> drm_i915_gem_request *rq)
> static void execlists_submit_requests(struct drm_i915_gem_request *rq0,
> struct drm_i915_gem_request *rq1)
> {
> + struct drm_i915_private *dev_priv = rq0->i915;
> +
> execlists_update_context(rq0);
>
> if (rq1)
> execlists_update_context(rq1);
>
> + spin_lock(&dev_priv->uncore.lock);
> + intel_uncore_forcewake_get__locked(dev_priv, FORCEWAKE_ALL);
My only problem with this is that it puts the onus on the caller to
remember to disable irqs first. (That would be a silent conflict with
the patch to move the submission to a kthread for example.)
What's the cost of being upfront with spin_lock_irqsave() here?
/* BUG_ON(!irqs_disabled()); */ ?
I'm quite happy to go with the comment here and since it doesn't make
the lockups any worse,
Reviewed-by: Chris Wilsno
-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 1/3] drm/i915/tdr: Initialize hangcheck struct for each engine
On Fri, Mar 18, 2016 at 08:07:54PM +, Arun Siluvery wrote:
> From: Tomas Elf
>
> Initialize hangcheck struct during driver load. Since we do the same after
> recovering from a reset, this is extracted into a helper function.
>
> Cc: Mika Kuoppala
> Signed-off-by: Tomas Elf
> Signed-off-by: Arun Siluvery
> ---
> drivers/gpu/drm/i915/i915_dma.c | 12
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_lrc.c| 2 +-
> drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++-
> 4 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 3f439a0..c5d1673 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -945,6 +945,16 @@ static void intel_init_dpio(struct drm_i915_private
> *dev_priv)
> }
> }
>
> +static void i915_hangcheck_init(struct drm_device *dev)
> +{
> + int i;
> + struct intel_engine_cs *engine;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + for_each_engine(engine, dev_priv, i)
> + intel_engine_init_hangcheck(engine);
> +}
> +
> static int i915_workqueues_init(struct drm_i915_private *dev_priv)
> {
> /*
> @@ -1233,6 +1243,8 @@ static int i915_driver_init_hw(struct drm_i915_private
> *dev_priv)
>
> i915_gem_load_init_fences(dev_priv);
>
> + i915_hangcheck_init(dev);
This is tautological. If we are clearing the per-engine hangcheck in
ring->init_hw() then we will do later anyway. So why now?
-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: Modify reset func to handle per engine resets
In full gpu reset we prime all engines and reset domains corresponding to
each engine. Per engine reset is just a special case of this process
wherein only a single engine is reset. This change is aimed to modify
relevant functions to achieve this. There are some other steps we carry out
in case of engine reset which are addressed in later patches.
Reset func now accepts a mask of all engines that need to be reset. Where
per engine resets are supported, error handler populates the mask
accordingly otherwise all engines are specified.
v2: ALL_ENGINES mask fixup, better for_each_ring_masked (Chris)
v3: Whitespace fixes (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 8 ++-
drivers/gpu/drm/i915/i915_gem.c | 14 +++---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_uncore.c | 87 -
6 files changed, 82 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 20e82008b8b6..3648b73b48da 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -881,7 +881,7 @@ int i915_reset(struct drm_device *dev)
simulated = dev_priv->gpu_error.stop_rings != 0;
- ret = intel_gpu_reset(dev);
+ ret = intel_gpu_reset(dev, ALL_ENGINES);
/* Also reset the gpu hangman. */
if (simulated) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 80b14f1ba302..0386310e59c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1971,6 +1971,10 @@ static inline struct drm_i915_private
*guc_to_i915(struct intel_guc *guc)
for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
for_each_if ring__) = &(dev_priv__)->ring[(i__)]),
intel_ring_initialized((ring__
+#define for_each_ring_masked(ring__, dev_priv__, mask__) \
+ for ((ring__) = &dev_priv->ring[0]; (ring__) <
&dev_priv->ring[I915_NUM_RINGS]; (ring__)++) \
+ for_each_if (intel_ring_flag((ring__)) & (mask__) &&
intel_ring_initialized((ring__)))
+
enum hdmi_force_audio {
HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
HDMI_AUDIO_OFF, /* force turn off HDMI audio */
@@ -2553,6 +2557,8 @@ struct drm_i915_cmd_table {
#define BLT_RING (1ring_mask & BSD2_RING)
#define HAS_BLT(dev) (INTEL_INFO(dev)->ring_mask & BLT_RING)
@@ -2681,7 +2687,7 @@ extern void i915_driver_postclose(struct drm_device *dev,
extern long i915_compat_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg);
#endif
-extern int intel_gpu_reset(struct drm_device *dev);
+extern int intel_gpu_reset(struct drm_device *dev, u32 engine_mask);
extern bool intel_has_gpu_reset(struct drm_device *dev);
extern int i915_reset(struct drm_device *dev);
extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b854af2c4141..4c0cdd5ee8cf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5012,13 +5012,13 @@ i915_gem_cleanup_ringbuffer(struct drm_device *dev)
for_each_ring(ring, dev_priv, i)
dev_priv->gt.cleanup_ring(ring);
-if (i915.enable_execlists)
-/*
- * Neither the BIOS, ourselves or any other kernel
- * expects the system to be in execlists mode on startup,
- * so we need to reset the GPU back to legacy mode.
- */
-intel_gpu_reset(dev);
+ if (i915.enable_execlists)
+ /*
+* Neither the BIOS, ourselves or any other kernel
+* expects the system to be in execlists mode on startup,
+* so we need to reset the GPU back to legacy mode.
+*/
+ intel_gpu_reset(dev, ALL_ENGINES);
}
static void
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5dd84e148bba..3251539a6cbe 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -413,7 +413,7 @@ void i915_gem_context_fini(struct drm_device *dev)
/* The only known way to stop the gpu from accessing the hw
context is
* to reset it. Do this as the very last operation to avoid
confusing
* other code, leading to spurious errors. */
- intel_gpu_reset(dev);
+ intel_gpu_reset(dev, ALL_ENGINES);
/* When default context is created and switched to, base object
refcount
* will be 2
Re: [Intel-gfx] [PATCH] drm/i915/userptr: Replace get_user_pages()
On 17/03/16 09:37, Chris Wilson wrote:
Although the long term future of get_user_pages_locked() itself is
doubtful, the kernel currently recommends:
/* get_user_pages should be phased out in favor of
* get_user_pages_locked|unlocked or get_user_pages_fast. Nothing
* should use get_user_pages because it cannot pass
* FAULT_FLAG_ALLOW_RETRY to handle_mm_fault.
*/
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 54088a4d6498..fa7d8a8b66ef 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -500,20 +500,22 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
pvec = drm_malloc_ab(npages, sizeof(struct page *));
if (pvec != NULL) {
struct mm_struct *mm = obj->userptr.mm->mm;
+ int locked = 1;
down_read(&mm->mmap_sem);
while (pinned < npages) {
- ret = get_user_pages(work->task, mm,
-obj->userptr.ptr + pinned *
PAGE_SIZE,
-npages - pinned,
-!obj->userptr.read_only, 0,
-pvec + pinned, NULL);
+ ret = get_user_pages_locked(work->task, mm,
+ obj->userptr.ptr + pinned *
PAGE_SIZE,
+ npages - pinned,
+ !obj->userptr.read_only, 0,
+ pvec + pinned, &locked);
if (ret < 0)
break;
pinned += ret;
}
- up_read(&mm->mmap_sem);
+ if (locked)
+ up_read(&mm->mmap_sem);
}
mutex_lock(&dev->struct_mutex);
Reviewed-by: Tvrtko Ursulin
Is it just cleanup or actually improves some real (as in hit by someone)
scenario?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix sparse warning for using false as NULL
On Wed, Mar 16, 2016 at 06:06:58PM +0200, Jani Nikula wrote:
> drivers/gpu/drm/i915/intel_dpll_mgr.c:1200:32: warning: Using plain integer
> as NULL pointer
>
> Fixes: 304b65cbdc8d ("drm/i915: Move SKL/KLB pll selection logic to
> intel_dpll_mgr.c")
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 74d5aecc0be5..e53d57c39056 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1197,7 +1197,7 @@ skl_get_dpll(struct intel_crtc *crtc, struct
> intel_crtc_state *crtc_state,
> ctrl1 |= DPLL_CTRL1_HDMI_MODE(0);
>
> if (!skl_ddi_calculate_wrpll(clock * 1000, &wrpll_params))
> - return false;
> + return NULL;
>
> cfgcr1 = DPLL_CFGCR1_FREQ_ENABLE |
>DPLL_CFGCR1_DCO_FRACTION(wrpll_params.dco_fraction) |
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] igt/gem_trtt: Exercise the TRTT hardware
On 3/11/2016 11:48 AM, akash.g...@intel.com wrote: From: Akash Goel This patch provides the testcase to exercise the TRTT hardware. Some platforms have an additional address translation hardware support in form of Tiled Resource Translation Table (TR-TT) which provides an extra level of abstraction over PPGTT. This is useful for mapping Sparse/Tiled texture resources. TR-TT is tightly coupled with PPGTT, a new instance of TR-TT will be required for a new PPGTT instance, but TR-TT may not enabled for every context. 1/16th of the 48bit PPGTT space is earmarked for the translation by TR-TT, which such chunk to use is conveyed to HW through a register. Any GFX address, which lies in that reserved 44 bit range will be translated through TR-TT first and then through PPGTT to get the actual physical address. TRTT is constructed as a 3 level tile Table. Each tile is 64KB is size which leaves behind 44-16=28 address bits. 28bits are partitioned as 9+9+10, and each level is contained within a 4KB page hence L3 and L2 is composed of 512 64b entries and L1 is composed of 1024 32b entries. There is a provision to keep TR-TT Tables in virtual space, where the pages of TRTT tables will be mapped to PPGTT. This is the adopted mode, as in this mode UMD will have a full control on TR-TT management, with bare minimum support from KMD. So the entries of L3 table will contain the PPGTT offset of L2 Table pages, similarly entries of L2 table will contain the PPGTT offset of L1 Table pages. The entries of L1 table will contain the PPGTT offset of BOs actually backing the Sparse resources. I915_GEM_CONTEXT_SETPARAM ioctl is used to request KMD to enable TRTT for a certain context, a new I915_CONTEXT_PARAM_ENABLE_TRTT param has been added to the CONTEXT_SETPARAM ioctl for that purpose. v2: - Add new wrapper function __gem_context_require_param and used that to detect the TR-TT support - Use igt_main macro, rename certain function, remove extra white space, cleanup the code (Chris) - Enhance the basic subtest to exercise all possible TR-TT segment start locations (i.e. 16 of them) & for every iteration create a new context. v3: - Get rid of some superfluous local variables (Chris) - Add asserts to validate whether the GFX address used in MI_STORE_DATA_IMM command is in canonical form & is correctly aligned or not (Chris) - Remove clearing of errno in has_trtt_support function (Chris) - Use the 48B_ADDRESS flag for batch buffer BO also (Chris) - Rebased. v4: - Add new subtest for invalid settings. - Add new local function query_trtt to check the Driver state (Chris) - Add new helper function gem_uses_64b_ppgtt to detect 64bit PPGTT support - Remove local functions uses_full_ppgtt & has_softpin_support, instead use existing wrappers gem_has_softpin & gem_uses_64b_ppgtt (Chris). - Remove redundant bit masking in emit_store_xxx functions (Chris). v5: - Add 2 new subtests checking the forceful eviction of active/hanging objects overlapping with the TR-TT segment (Chris). - Move gen8_canonical_addr to igt_aux as its needed by other tests also, which does soft pinning, and not just gem_softpin (Michel) Cc: Chris Wilson Cc: Michel Thierry Signed-off-by: Akash Goel Test looks good to me. Reviewed-by: Michel Thierry ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Modify reset func to handle per engine resets
Mika Kuoppala writes:
> [ text/plain ]
> In full gpu reset we prime all engines and reset domains corresponding to
> each engine. Per engine reset is just a special case of this process
> wherein only a single engine is reset. This change is aimed to modify
> relevant functions to achieve this. There are some other steps we carry out
> in case of engine reset which are addressed in later patches.
>
> Reset func now accepts a mask of all engines that need to be reset. Where
> per engine resets are supported, error handler populates the mask
> accordingly otherwise all engines are specified.
>
> v2: ALL_ENGINES mask fixup, better for_each_ring_masked (Chris)
> v3: Whitespace fixes (Chris)
> v4: Rebase due to s/ring/engine
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> Signed-off-by: Arun Siluvery
> Reviewed-by: Chris Wilson
Pushed to dinq. Thank you all.
-Mika
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 8 ++-
> drivers/gpu/drm/i915/i915_gem.c | 14 +++---
> drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 2 +
> drivers/gpu/drm/i915/intel_uncore.c | 87
> -
> 6 files changed, 82 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 20e82008b8b6..3648b73b48da 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -881,7 +881,7 @@ int i915_reset(struct drm_device *dev)
>
> simulated = dev_priv->gpu_error.stop_rings != 0;
>
> - ret = intel_gpu_reset(dev);
> + ret = intel_gpu_reset(dev, ALL_ENGINES);
>
> /* Also reset the gpu hangman. */
> if (simulated) {
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fd1ed66dd298..8940b38ed57f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1971,6 +1971,10 @@ static inline struct drm_i915_private
> *guc_to_i915(struct intel_guc *guc)
> for ((i__) = 0; (i__) < I915_NUM_ENGINES; (i__)++) \
> for_each_if ring__) = &(dev_priv__)->engine[(i__)]),
> intel_engine_initialized((ring__
>
> +#define for_each_engine_masked(engine__, dev_priv__, mask__) \
> + for ((engine__) = &dev_priv->engine[0]; (engine__) <
> &dev_priv->engine[I915_NUM_ENGINES]; (engine__)++) \
> + for_each_if (intel_engine_flag((engine__)) & (mask__) &&
> intel_engine_initialized((engine__)))
> +
> enum hdmi_force_audio {
> HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
> HDMI_AUDIO_OFF, /* force turn off HDMI audio */
> @@ -2553,6 +2557,8 @@ struct drm_i915_cmd_table {
> #define BLT_RING (1< #define VEBOX_RING (1< #define BSD2_RING(1< +#define ALL_ENGINES (~0)
> +
> #define HAS_BSD(dev) (INTEL_INFO(dev)->ring_mask & BSD_RING)
> #define HAS_BSD2(dev)(INTEL_INFO(dev)->ring_mask & BSD2_RING)
> #define HAS_BLT(dev) (INTEL_INFO(dev)->ring_mask & BLT_RING)
> @@ -2681,7 +2687,7 @@ extern void i915_driver_postclose(struct drm_device
> *dev,
> extern long i915_compat_ioctl(struct file *filp, unsigned int cmd,
> unsigned long arg);
> #endif
> -extern int intel_gpu_reset(struct drm_device *dev);
> +extern int intel_gpu_reset(struct drm_device *dev, u32 engine_mask);
> extern bool intel_has_gpu_reset(struct drm_device *dev);
> extern int i915_reset(struct drm_device *dev);
> extern unsigned long i915_chipset_val(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 31652c1da761..a25109aa033c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5012,13 +5012,13 @@ i915_gem_cleanup_engines(struct drm_device *dev)
> for_each_engine(engine, dev_priv, i)
> dev_priv->gt.cleanup_engine(engine);
>
> -if (i915.enable_execlists)
> -/*
> - * Neither the BIOS, ourselves or any other kernel
> - * expects the system to be in execlists mode on startup,
> - * so we need to reset the GPU back to legacy mode.
> - */
> -intel_gpu_reset(dev);
> + if (i915.enable_execlists)
> + /*
> + * Neither the BIOS, ourselves or any other kernel
> + * expects the system to be in execlists mode on startup,
> + * so we need to reset the GPU back to legacy mode.
> + */
> + intel_gpu_reset(dev, ALL_ENGINES);
> }
>
> static void
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 1993449ab7c5..c114665a24b3 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -413,7 +413,7
Re: [Intel-gfx] [RFC PATCH 07/10] drm/i915: abstract get config for cpu transcoder
On Wed, Mar 16, 2016 at 05:26:24PM +0200, Jani Nikula wrote:
> On Wed, 16 Mar 2016, Ville Syrjälä wrote:
> > [ text/plain ]
> > On Tue, Mar 15, 2016 at 09:51:15PM +0200, Jani Nikula wrote:
> >> Makes it neater to add the same for DSI transcoder. No functional
> >> changes.
> >>
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/i915/intel_display.c | 83
> >>
> >> 1 file changed, 47 insertions(+), 36 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index e485c1f9ca2b..842467528892 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -9893,6 +9893,49 @@ static void haswell_get_ddi_pll(struct
> >> drm_i915_private *dev_priv,
> >>pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
> >> }
> >>
> >> +static bool hsw_get_trans_config(struct intel_crtc *crtc,
> >> + struct intel_crtc_state *pipe_config,
> >> + unsigned long *power_domain_mask)
> >> +{
> >
> > To be consistent with existing practices we should probably call this
> > ..._get_hw_state, or maybe ..._get_transcoder_state (if we want to
> > follow the get_ddi_port_state() below).
> >
> >> + struct drm_device *dev = crtc->base.dev;
> >> + struct drm_i915_private *dev_priv = dev->dev_private;
> >> + enum intel_display_power_domain power_domain;
> >> + u32 tmp;
> >> +
> >> + pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> >> +
> >> + tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
> >> + if (tmp & TRANS_DDI_FUNC_ENABLE) {
> >
> > I guess as a followup we should do the
> > intel_display_power_get_if_enabled() for the edp transcoder already
> > before this read. Just need to be careful that we don't grab it twice
> > then.
>
> I checked this while writing the code, and IIUC
> TRANS_DDI_FUNC_CTL(TRANSCODER_EDP) is in always on power.
True, but it does look a bit odd to the eye on the first glance to read
the reg just before grabbing the power reference.
>
> BR,
> Jani.
>
> >
> >> + enum pipe trans_edp_pipe;
> >> + switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
> >> + default:
> >> + WARN(1, "unknown pipe linked to edp transcoder\n");
> >> + case TRANS_DDI_EDP_INPUT_A_ONOFF:
> >> + case TRANS_DDI_EDP_INPUT_A_ON:
> >> + trans_edp_pipe = PIPE_A;
> >> + break;
> >> + case TRANS_DDI_EDP_INPUT_B_ONOFF:
> >> + trans_edp_pipe = PIPE_B;
> >> + break;
> >> + case TRANS_DDI_EDP_INPUT_C_ONOFF:
> >> + trans_edp_pipe = PIPE_C;
> >> + break;
> >> + }
> >> +
> >> + if (trans_edp_pipe == crtc->pipe)
> >> + pipe_config->cpu_transcoder = TRANSCODER_EDP;
> >> + }
> >> +
> >> + power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
> >> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> >> + return false;
> >> + *power_domain_mask |= BIT(power_domain);
> >> +
> >> + tmp = I915_READ(PIPECONF(pipe_config->cpu_transcoder));
> >> +
> >> + return tmp & PIPECONF_ENABLE;
> >> +}
> >> +
> >> static void haswell_get_ddi_port_state(struct intel_crtc *crtc,
> >> struct intel_crtc_state *pipe_config)
> >> {
> >> @@ -9943,48 +9986,18 @@ static bool haswell_get_pipe_config(struct
> >> intel_crtc *crtc,
> >>struct drm_i915_private *dev_priv = dev->dev_private;
> >>enum intel_display_power_domain power_domain;
> >>unsigned long power_domain_mask;
> >> - uint32_t tmp;
> >> - bool ret;
> >> + bool active;
> >>
> >>power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
> >>if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> >>return false;
> >>power_domain_mask = BIT(power_domain);
> >>
> >> - ret = false;
> >> -
> >> - pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> >>pipe_config->shared_dpll = NULL;
> >>
> >> - tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
> >> - if (tmp & TRANS_DDI_FUNC_ENABLE) {
> >> - enum pipe trans_edp_pipe;
> >> - switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
> >> - default:
> >> - WARN(1, "unknown pipe linked to edp transcoder\n");
> >> - case TRANS_DDI_EDP_INPUT_A_ONOFF:
> >> - case TRANS_DDI_EDP_INPUT_A_ON:
> >> - trans_edp_pipe = PIPE_A;
> >> - break;
> >> - case TRANS_DDI_EDP_INPUT_B_ONOFF:
> >> - trans_edp_pipe = PIPE_B;
> >> - break;
> >> - case TRANS_DDI_EDP_INPUT_C_ONOFF:
> >> - trans_edp_pipe = PIPE_C;
> >> - break;
> >> - }
> >> -
> >> - if (trans_edp_pipe == crtc->pipe)
> >> - pipe_config->cpu
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Codify our assumption that the Global GTT is <= 4GiB
On Fri, Mar 18, 2016 at 10:56:55AM +, Tvrtko Ursulin wrote:
>
> On 18/03/16 08:42, Joonas Lahtinen wrote:
> >From: Chris Wilson
> >
> >Throughout the code base, we use u32 for offsets into the global GTT. If
> >we ever see any hardware with a larger GGTT, then we run the real risk
> >of silent corruption. So test for our assumption up front so that we
> >have a nice reminder should the time come when it fails.
> >
> >Signed-off-by: Chris Wilson
> >Cc: Ville Syrjälä
> >Cc: Daniel Vetter
> >Signed-off-by: Joonas Lahtinen
> >[Rebased and changed 1ull -> 1ULL]
> >---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >index 8a9fa03..ba144ba 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >@@ -3191,6 +3191,13 @@ int i915_gem_gtt_init(struct drm_device *dev)
> > if (ret)
> > return ret;
> >
> >+if ((ggtt->base.total - 1) >> 32) {
> >+DRM_ERROR("We never expected a Global GTT with more than 32bits
> >of address space! Found %lldM!\n",
> >+ ggtt->base.total >> 20);
>
> MB or MiB?
if ((ggtt->base.total - 1) >> 32) {
char buf[10];
string_get_size(ggtt->base.total, 1, STRING_UNITS_2, buf, sizeof(buf));
DRM_ERROR("We never expected a Global GTT with more than 32bits of
address space! Found %s [%dbits]\n",
buf, fls(size));
}
-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] drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
On Wed, Mar 16, 2016 at 03:44:37PM -0400, Lyude Paul wrote:
> On Wed, 2016-03-16 at 21:39 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 16, 2016 at 03:18:04PM -0400, Lyude wrote:
> > >
> > > After unplugging a DP MST display from the system, we have to go through
> > > and destroy all of the DRM connectors associated with it since none of
> > > them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector()
> > > doesn't do a good enough job of ensuring that throughout the destruction
> > > process that no modesettings can be done with the connectors. As it is
> > > right now, intel_dp_destroy_mst_connector() works like this:
> > >
> > > * Take all modeset locks
> > > * Clear the configuration of the crtc on the connector, if there is one
> > > * Drop all modeset locks, this is required because of circular
> > > dependency issues that arise with trying to remove the connector from
> > > sysfs with modeset locks held
> > > * Unregister the connector
> > > * Take all modeset locks, again
> > > * Do the rest of the required cleaning for destroying the connector
> > > * Finally drop all modeset locks for good
> > So pretty much what I suspected
> > https://lists.freedesktop.org/archives/intel-gfx/2016-February/087734.html
> >
> > >
> > >
> > > This only works sometimes. During the destruction process, it's very
> > > possible that a userspace application will attempt to do a modesetting
> > > using the connector. When we drop the modeset locks, an ioctl handler
> > > such as drm_mode_setcrtc has the oppurtunity to take all of the modeset
> > > locks from us. When this happens, one thing leads to another and
> > > eventually we end up committing a mode with the non-existent connector:
> > >
> > > [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to
> > > enable link training
> > > [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
> > > [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel
> > > equalization
> > > [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f
> > > [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
> > >
> > > And in some cases, such as with the T460s using an MST dock, this
> > > results in breaking modesetting and/or panicking the system.
> > Are these just kernel oopses etc.? If the hardware gets upset from
> > modesetting when the sink is gone, well, then we still have a problem
> > because the user can of course yank the cable while the modeset is already
> > underway.
> It is more then that. Unfortunately though, fixing that part is not as easy.
> We
> never expect an atomic modesetting commit to fail, but unfortunately any code
> having to do with turning on DP MST has the chance of failing and we turn on
> DP
> MST during commits. So fixing that would take moving quite a bit of code
> around.
SST has the same problems really. The sink may be gone so link training
etc. just won't succeed. But we should still finish the modeset without
killing the system or something.
>
> >
> > >
> > >
> > > To work around this, we now unregister the connector at the very
> > > beginning of intel_dp_destroy_mst_connector(), grab all the modesetting
> > > locks, and then hold them until we finish the rest of the function.
> > >
> > > CC: sta...@vger.kernel.org
> > > Signed-off-by: Lyude
> > > Signed-off-by: Rob Clark
> > These sobs don't make much sense to me.
> I should have mentioned that Rob Clark was the one who came up with the idea
> of
> just moving the connector->unregister() call to the top of the function.
>
> >
> > Patch itself does make sense to me, so
> > Reviewed-by: Ville Syrjälä
> >
> > >
> > > ---
> > > drivers/gpu/drm/i915/intel_dp_mst.c | 6 ++
> > > 1 file changed, 2 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index fa0dabf..b21ac88 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -499,6 +499,8 @@ static void intel_dp_destroy_mst_connector(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > > struct intel_connector *intel_connector =
> > > to_intel_connector(connector);
> > > struct drm_device *dev = connector->dev;
> > >
> > > + intel_connector->unregister(intel_connector);
> > > +
> > > /* need to nuke the connector */
> > > drm_modeset_lock_all(dev);
> > > if (connector->state->crtc) {
> > > @@ -512,11 +514,7 @@ static void intel_dp_destroy_mst_connector(struct
> > > drm_dp_mst_topology_mgr *mgr,
> > >
> > > WARN(ret, "Disabling mst crtc failed with %i\n", ret);
> > > }
> > > - drm_modeset_unlock_all(dev);
> > >
> > > - intel_connector->unregister(intel_connector);
> > > -
> > > - drm_modeset_lock_all(dev);
> > > intel_connector_remove_from_fbdev(intel_connector);
> > > drm_connector_cleanup(connector);
> > > drm_modeset_unlock_all(dev);
> > > --
> > > 2.5.0
> > >
> > > __
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Remove unused variable in i915_gem_request_add_to_client
On Wed, Mar 16, 2016 at 03:40:52PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Signed-off-by: Tvrtko Ursulin This function is horrible, this is slightly better but not much. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] prime_mmap_coherency: Add return error tests for prime sync ioctl
On Fri, Mar 18, 2016 at 03:08:56PM -0300, Tiago Vignatti wrote:
> This patch adds ioctl-errors subtest to be used for exercising prime sync
> ioctl
> errors.
>
> The subtest constantly interrupts via signals a function doing concurrent blit
> to stress out the right usage of prime_sync_*, making sure these ioctl errors
> are handled accordingly. Important to note that in case of failure (e.g. in a
> case where the ioctl wouldn't try again in a return error) this test does not
> reliably catch the problem with 100% of accuracy.
>
> v2: fix prime sync direction when reading mmap'ed file.
> v3: change the upper bound using time rather than loops
>
> Cc: Chris Wilson
> Signed-off-by: Tiago Vignatti
I'm probably blind, but where is the reviewed kernel patch for this? If
it's somewhere hidden, please resubmit with all the whizzbang stuff needed
for merging added ;-)
Thanks, Daniel
> ---
> tests/prime_mmap_coherency.c | 89
>
> 1 file changed, 89 insertions(+)
>
> diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
> index 180d8a4..d2b2a4f 100644
> --- a/tests/prime_mmap_coherency.c
> +++ b/tests/prime_mmap_coherency.c
> @@ -180,6 +180,90 @@ static void test_write_flush(bool expect_stale_cache)
> munmap(ptr_cpu, width * height);
> }
>
> +static void blit_and_cmp(void)
> +{
> + drm_intel_bo *bo_1;
> + drm_intel_bo *bo_2;
> + uint32_t *ptr_cpu;
> + uint32_t *ptr2_cpu;
> + int dma_buf_fd, dma_buf2_fd, i;
> + int local_fd;
> + drm_intel_bufmgr *local_bufmgr;
> + struct intel_batchbuffer *local_batch;
> +
> + /* recreate process local variables */
> + local_fd = drm_open_driver(DRIVER_INTEL);
> + local_bufmgr = drm_intel_bufmgr_gem_init(local_fd, 4096);
> + igt_assert(local_bufmgr);
> +
> + local_batch = intel_batchbuffer_alloc(local_bufmgr,
> intel_get_drm_devid(local_fd));
> + igt_assert(local_batch);
> +
> + bo_1 = drm_intel_bo_alloc(local_bufmgr, "BO 1", width * height * 4,
> 4096);
> + dma_buf_fd = prime_handle_to_fd_for_mmap(local_fd, bo_1->handle);
> + igt_skip_on(errno == EINVAL);
> +
> + ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
> + MAP_SHARED, dma_buf_fd, 0);
> + igt_assert(ptr_cpu != MAP_FAILED);
> +
> + bo_2 = drm_intel_bo_alloc(local_bufmgr, "BO 2", width * height * 4,
> 4096);
> + dma_buf2_fd = prime_handle_to_fd_for_mmap(local_fd, bo_2->handle);
> +
> + ptr2_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
> + MAP_SHARED, dma_buf2_fd, 0);
> + igt_assert(ptr2_cpu != MAP_FAILED);
> +
> + /* Fill up BO 1 with '1's and BO 2 with '0's */
> + prime_sync_start(dma_buf_fd, true);
> + memset(ptr_cpu, 0x11, width * height);
> + prime_sync_end(dma_buf_fd, true);
> +
> + prime_sync_start(dma_buf2_fd, true);
> + memset(ptr2_cpu, 0x00, width * height);
> + prime_sync_end(dma_buf2_fd, true);
> +
> + /* Copy BO 1 into BO 2, using blitter. */
> + intel_copy_bo(local_batch, bo_2, bo_1, width * height);
> + usleep(0); /* let someone else claim the mutex */
> +
> + /* Compare BOs. If prime_sync_* were executed properly, the caches
> + * should be synced. */
> + prime_sync_start(dma_buf2_fd, false);
> + for (i = 0; i < (width * height) / 4; i++)
> + igt_fail_on_f(ptr2_cpu[i] != 0x, "Found 0x%08x at
> offset 0x%08x\n", ptr2_cpu[i], i);
> + prime_sync_end(dma_buf2_fd, false);
> +
> + drm_intel_bo_unreference(bo_1);
> + drm_intel_bo_unreference(bo_2);
> + munmap(ptr_cpu, width * height);
> + munmap(ptr2_cpu, width * height);
> +}
> +
> +/*
> + * Constantly interrupt concurrent blits to stress out prime_sync_* and make
> + * sure these ioctl errors are handled accordingly.
> + *
> + * Important to note that in case of failure (e.g. in a case where the ioctl
> + * wouldn't try again in a return error) this test does not reliably catch
> the
> + * problem with 100% of accuracy.
> + */
> +static void test_ioctl_errors(void)
> +{
> + int ncpus = sysconf(_SC_NPROCESSORS_ONLN);
> +
> + igt_fork_signal_helper();
> + for (int num_children = 1; num_children <= 8 *ncpus; num_children <<=
> 1) {
> + igt_fork(child, num_children) {
> + struct timespec start = {};
> + while (igt_nsec_elapsed(&start) <= num_children)
> + blit_and_cmp();
> + }
> + igt_waitchildren();
> + }
> + igt_stop_signal_helper();
> +}
> +
> int main(int argc, char **argv)
> {
> int i;
> @@ -235,6 +319,11 @@ int main(int argc, char **argv)
> igt_fail_on_f(!stale, "couldn't find any stale cache lines\n");
> }
>
> + igt_subtest("ioctl-errors") {
> + igt_info("exercising concurrent blit to get ioctl errors\n");
> + test_ioctl_errors();
> + }
> +
>
[Intel-gfx] [PATCH i-g-t 4/6] lib: add crc comparison function without an assert
Signed-off-by: Lionel Landwerlin
---
lib/igt_debugfs.c | 17 +
lib/igt_debugfs.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index c291ef3..a32ed78 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -252,6 +252,23 @@ bool igt_debugfs_search(const char *filename, const char
*substring)
* @a: first pipe CRC value
* @b: second pipe CRC value
*
+ * Compares two CRC values.
+ */
+bool igt_crc_equal(igt_crc_t *a, igt_crc_t *b)
+{
+ int i;
+
+ for (i = 0; i < a->n_words; i++)
+ if (a->crc[i] != b->crc[i])
+ return false;
+ return true;
+}
+
+/**
+ * igt_assert_crc_equal:
+ * @a: first pipe CRC value
+ * @b: second pipe CRC value
+ *
* Compares two CRC values and fails the testcase if they don't match with
* igt_fail(). Note that due to CRC collisions CRC based testcase can only
* assert that CRCs match, never that they are different. Otherwise there might
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index dac8413..d08fc23 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -124,6 +124,7 @@ __attribute__((warn_unused_result))
int igt_pipe_crc_get_crcs(igt_pipe_crc_t *pipe_crc, int n_crcs,
igt_crc_t **out_crcs);
void igt_pipe_crc_collect_crc(igt_pipe_crc_t *pipe_crc, igt_crc_t *out_crc);
+bool igt_crc_equal(igt_crc_t *a, igt_crc_t *b);
/*
* Drop caches
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915: Propagating correct error codes to the userspace
From: Ankitprasad Sharma
Propagating correct error codes to userspace by using ERR_PTR and
PTR_ERR macros for stolen memory based object allocation. We generally
return -ENOMEM to the user whenever there is a failure in object
allocation. This patch helps user to identify the correct reason for the
failure and not just -ENOMEM each time.
v2: Moved the patch up in the series, added error propagation for
i915_gem_alloc_object too (Chris)
v3: Removed storing of error pointer inside structs, Corrected error
propagation in caller functions (Chris)
v4: Remove assignments inside the predicate (Chris)
v5: Removed unnecessary initializations, updated kerneldoc for
i915_guc_client, corrected missed error pointer handling (Tvrtko)
v6: Use ERR_CAST/temporary variable to avoid storing invalid pointer
in a common field (Chris)
v7: Resolved rebasing conflicts (Ankit)
v8: Removed redundant code (Chris)
v9: Rebase
v10: Rebase, resolve merge conflicts
Signed-off-by: Ankitprasad Sharma
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 23 ++--
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 4 +--
drivers/gpu/drm/i915/i915_gem_context.c | 4 +--
drivers/gpu/drm/i915/i915_gem_render_state.c | 7 ++--
drivers/gpu/drm/i915/i915_gem_stolen.c | 53 +++-
drivers/gpu/drm/i915/i915_guc_submission.c | 52 +--
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 6 ++--
drivers/gpu/drm/i915/intel_lrc.c | 10 +++---
drivers/gpu/drm/i915/intel_overlay.c | 4 +--
drivers/gpu/drm/i915/intel_pm.c | 7 ++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 21 +--
12 files changed, 110 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 43aacb1..7dfa026 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -397,19 +397,18 @@ i915_gem_alloc_object_stolen(struct drm_device *dev,
size_t size)
mutex_lock(&dev->struct_mutex);
obj = i915_gem_object_create_stolen(dev, size);
- if (!obj) {
- mutex_unlock(&dev->struct_mutex);
- return NULL;
- }
+ if (IS_ERR(obj))
+ goto out;
/* Always clear fresh buffers before handing to userspace */
ret = i915_gem_object_clear(obj);
if (ret) {
drm_gem_object_unreference(&obj->base);
- mutex_unlock(&dev->struct_mutex);
- return NULL;
+ obj = ERR_PTR(ret);
+ goto out;
}
+out:
mutex_unlock(&dev->struct_mutex);
return obj;
}
@@ -444,8 +443,8 @@ i915_gem_create(struct drm_file *file,
return -EINVAL;
}
- if (obj == NULL)
- return -ENOMEM;
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
ret = drm_gem_handle_create(file, &obj->base, &handle);
/* drop reference from allocate - handle holds it now */
@@ -4560,14 +4559,16 @@ struct drm_i915_gem_object
*i915_gem_alloc_object(struct drm_device *dev,
struct drm_i915_gem_object *obj;
struct address_space *mapping;
gfp_t mask;
+ int ret;
obj = i915_gem_object_alloc(dev);
if (obj == NULL)
- return NULL;
+ return ERR_PTR(-ENOMEM);
- if (drm_gem_object_init(dev, &obj->base, size) != 0) {
+ ret = drm_gem_object_init(dev, &obj->base, size);
+ if (ret) {
i915_gem_object_free(obj);
- return NULL;
+ return ERR_PTR(ret);
}
mask = GFP_HIGHUSER | __GFP_RECLAIMABLE;
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 7bf2f3f..d79caa2 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -135,8 +135,8 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
int ret;
obj = i915_gem_alloc_object(pool->dev, size);
- if (obj == NULL)
- return ERR_PTR(-ENOMEM);
+ if (IS_ERR(obj))
+ return obj;
ret = i915_gem_object_get_pages(obj);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 1993449..af76e36 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -179,8 +179,8 @@ i915_gem_alloc_context_obj(struct drm_device *dev, size_t
size)
int ret;
obj = i915_gem_alloc_object(dev, size);
- if (obj == NULL)
- return ERR_PTR(-ENOMEM);
+ if (IS_ERR(obj))
+ return obj;
/*
* Try to make the context utilize L3 as well as LLC.
diff --git a/drivers/gpu/drm/i
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen9: add WaClearFlowControlGpgpuContextSave (rev3)
== Series Details == Series: drm/i915/gen9: add WaClearFlowControlGpgpuContextSave (rev3) URL : https://patchwork.freedesktop.org/series/4272/ State : failure == Summary == Series 4272v3 drm/i915/gen9: add WaClearFlowControlGpgpuContextSave http://patchwork.freedesktop.org/api/1.0/series/4272/revisions/3/mbox/ Test gem_ringfill: Subgroup basic-default-s3: dmesg-warn -> PASS (bsw-nuc-2) Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> DMESG-WARN (hsw-brixbox) Subgroup basic-plain-flip: dmesg-warn -> PASS (hsw-gt2) dmesg-warn -> PASS (hsw-brixbox) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-c: pass -> SKIP (hsw-brixbox) Subgroup nonblocking-crc-pipe-a: dmesg-warn -> PASS (hsw-brixbox) Subgroup read-crc-pipe-b: dmesg-warn -> PASS (hsw-gt2) Test pm_rpm: Subgroup basic-rte: pass -> DMESG-WARN (hsw-gt2) bdw-nuci7total:194 pass:181 dwarn:0 dfail:0 fail:0 skip:13 bdw-ultratotal:194 pass:173 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:194 pass:156 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:194 pass:155 dwarn:4 dfail:0 fail:0 skip:35 hsw-brixbox total:194 pass:170 dwarn:1 dfail:0 fail:0 skip:23 hsw-gt2 total:194 pass:176 dwarn:1 dfail:0 fail:0 skip:17 ivb-t430stotal:194 pass:169 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:194 pass:183 dwarn:0 dfail:0 fail:0 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_1622/ 7107208595602ace943fb5afa0de1de45d62c2b8 drm-intel-nightly: 2016y-03m-17d-08h-36m-48s UTC integration manifest 2b37e8a951958145dbc808de3fbbdf4a54988fda drm/i915/gen9: add WaClearFlowControlGpgpuContextSave ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: abstract get config for cpu transcoder
On Fri, Mar 18, 2016 at 05:05:41PM +0200, Jani Nikula wrote:
> Makes it neater to add the same for DSI transcoder. No functional
> changes.
>
> v2: rename to hsw_get_transcoder_state and add a comment about grabbing
> power reference (Ville)
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 87
> +---
> 1 file changed, 51 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index eece50ed3ea6..98d8b563b9a1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9910,6 +9910,53 @@ static void haswell_get_ddi_pll(struct
> drm_i915_private *dev_priv,
> pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
> }
>
> +static bool hsw_get_transcoder_state(struct intel_crtc *crtc,
> + struct intel_crtc_state *pipe_config,
> + unsigned long *power_domain_mask)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + enum intel_display_power_domain power_domain;
> + u32 tmp;
> +
> + pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> +
> + /*
> + * XXX: Do intel_display_power_get_if_enabled before reading this (for
> + * consistency and less surprising code; it's in always on power).
> + */
> + tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
> + if (tmp & TRANS_DDI_FUNC_ENABLE) {
> + enum pipe trans_edp_pipe;
> + switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
> + default:
> + WARN(1, "unknown pipe linked to edp transcoder\n");
> + case TRANS_DDI_EDP_INPUT_A_ONOFF:
> + case TRANS_DDI_EDP_INPUT_A_ON:
> + trans_edp_pipe = PIPE_A;
> + break;
> + case TRANS_DDI_EDP_INPUT_B_ONOFF:
> + trans_edp_pipe = PIPE_B;
> + break;
> + case TRANS_DDI_EDP_INPUT_C_ONOFF:
> + trans_edp_pipe = PIPE_C;
> + break;
> + }
> +
> + if (trans_edp_pipe == crtc->pipe)
> + pipe_config->cpu_transcoder = TRANSCODER_EDP;
> + }
> +
> + power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> + return false;
> + *power_domain_mask |= BIT(power_domain);
> +
> + tmp = I915_READ(PIPECONF(pipe_config->cpu_transcoder));
> +
> + return tmp & PIPECONF_ENABLE;
> +}
> +
> static void haswell_get_ddi_port_state(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config)
> {
> @@ -9960,48 +10007,18 @@ static bool haswell_get_pipe_config(struct
> intel_crtc *crtc,
> struct drm_i915_private *dev_priv = dev->dev_private;
> enum intel_display_power_domain power_domain;
> unsigned long power_domain_mask;
> - uint32_t tmp;
> - bool ret;
> + bool active;
>
> power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
> if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> return false;
> power_domain_mask = BIT(power_domain);
>
> - ret = false;
> -
> - pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> pipe_config->shared_dpll = NULL;
>
> - tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
> - if (tmp & TRANS_DDI_FUNC_ENABLE) {
> - enum pipe trans_edp_pipe;
> - switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
> - default:
> - WARN(1, "unknown pipe linked to edp transcoder\n");
> - case TRANS_DDI_EDP_INPUT_A_ONOFF:
> - case TRANS_DDI_EDP_INPUT_A_ON:
> - trans_edp_pipe = PIPE_A;
> - break;
> - case TRANS_DDI_EDP_INPUT_B_ONOFF:
> - trans_edp_pipe = PIPE_B;
> - break;
> - case TRANS_DDI_EDP_INPUT_C_ONOFF:
> - trans_edp_pipe = PIPE_C;
> - break;
> - }
> -
> - if (trans_edp_pipe == crtc->pipe)
> - pipe_config->cpu_transcoder = TRANSCODER_EDP;
> - }
> + active = hsw_get_transcoder_state(crtc, pipe_config,
> &power_domain_mask);
>
> - power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
> - if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> - goto out;
> - power_domain_mask |= BIT(power_domain);
> -
> - tmp = I915_READ(PIPECONF(pipe_config->cpu_transcoder));
> - if (!(tmp & PIPECONF_ENABLE))
> + if (!active)
> goto out;
>
> haswell_get_ddi_port_state(crtc, pipe_config);
> @@ -1003
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use GPLL ref clock to calculate GPU freqs on VLV/CHV
On Wed, Mar 16, 2016 at 07:17:51PM +0200, Imre Deak wrote:
> On Fri, 2016-03-04 at 21:43 +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Extract the GPLL reference frequency from CCK and use it in the
> > GPU freq<->opcode conversions on VLV/CHV. This eliminates all the
> > assumptions we have about which divider is used for which czclk
> > frequency.
> >
> > Note that unlike most clocks from CCK, the GPLL ref clock is a divided
> > down version of the CZ clock rather than the HPLL clock. CZ clock itself
> > is a divided down version of the HPLL clock though, so in effect it just
> > gets divided down twice.
> >
> > While at it, throw in a few comments explaining the remaining constants
> > for anyone who later wants to compare this to the spreadsheets.
> >
> > Signed-off-by: Ville Syrjälä
>
> Looks ok. The relevant info is spread across multiple documents but
> based on what I gathered this is ok and the old and new way of
> calculation matches, so:
> Reviewed-by: Imre Deak
>
> Some notes:
> For clarity, I'd rename *_gpu_freq to *_gpu_opcode_to_freq and
> *_freq_opcode to *_gpu_freq_to_opcode and mention that the CHV CU/CU2X
> clocks are also known as slow/fast clock, so it better matches the VLV
> code.
Well I think the slow/fast names might be more of a leftover from VLV,
ie. someone just forgot to update the names in bunch of the docs for
CHV. But adding a note might be prudent to avoid people having to
wonder about it.
>
> The entries for VLV 320/400MHz CZ clock are missing from the tables
> that I saw, which is one justification for this change, since we don't
> know if vlv_gpu_freq_div() was correct.
I don't think VLV had 320 or 400 SKUs.
>
> --Imre
>
>
>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_display.c | 19 ++---
> > drivers/gpu/drm/i915/intel_drv.h | 2 +
> > drivers/gpu/drm/i915/intel_pm.c | 74
> > +---
> > 5 files changed, 44 insertions(+), 53 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index f37ac120a29d..95f77cd0ce17 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1166,6 +1166,7 @@ struct intel_gen6_power_mgmt {
> > u8 efficient_freq; /* AKA RPe. Pre-determined balanced frequency */
> > u8 rp1_freq;/* "less than" RP0 power/freqency */
> > u8 rp0_freq;/* Non-overclocked max frequency. */
> > + u16 gpll_ref_freq; /* vlv/chv GPLL reference frequency */
> >
> > u8 up_threshold; /* Current %busy required to uplock */
> > u8 down_threshold; /* Current %busy required to downclock */
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 7dfc4007f3fa..aa21bfc06a24 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -785,6 +785,7 @@ enum skl_disp_power_wells {
> > #define DSI_PLL_M1_DIV_SHIFT 0
> > #define DSI_PLL_M1_DIV_MASK (0x1ff << 0)
> > #define CCK_CZ_CLOCK_CONTROL 0x62
> > +#define CCK_GPLL_CLOCK_CONTROL 0x67
> > #define CCK_DISPLAY_CLOCK_CONTROL 0x6b
> > #define CCK_DISPLAY_REF_CLOCK_CONTROL 0x6c
> > #define CCK_TRUNK_FORCE_ON(1 << 17)
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 62d36a7b3398..ba50de534f9a 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -147,15 +147,12 @@ static int valleyview_get_vco(struct drm_i915_private
> > *dev_priv)
> > return vco_freq[hpll_freq] * 1000;
> > }
> >
> > -static int vlv_get_cck_clock_hpll(struct drm_i915_private *dev_priv,
> > - const char *name, u32 reg)
> > +int vlv_get_cck_clock(struct drm_i915_private *dev_priv,
> > + const char *name, u32 reg, int ref_freq)
> > {
> > u32 val;
> > int divider;
> >
> > - if (dev_priv->hpll_freq == 0)
> > - dev_priv->hpll_freq = valleyview_get_vco(dev_priv);
> > -
> > mutex_lock(&dev_priv->sb_lock);
> > val = vlv_cck_read(dev_priv, reg);
> > mutex_unlock(&dev_priv->sb_lock);
> > @@ -166,7 +163,17 @@ static int vlv_get_cck_clock_hpll(struct
> > drm_i915_private *dev_priv,
> > (divider << CCK_FREQUENCY_STATUS_SHIFT),
> > "%s change in progress\n", name);
> >
> > - return DIV_ROUND_CLOSEST(dev_priv->hpll_freq << 1, divider + 1);
> > + return DIV_ROUND_CLOSEST(ref_freq << 1, divider + 1);
> > +}
> > +
> > +static int vlv_get_cck_clock_hpll(struct drm_i915_private *dev_priv,
> > + const char *name, u32 reg)
> > +{
> > + if (dev_priv->hpll_freq == 0)
> > + dev_priv->hpll_
[Intel-gfx] [PATCH 02/10] drm/i915: Introduce i915_gem_object_get_dma_address()
From: Chris Wilson
This utility function is a companion to i915_gem_object_get_page() that
uses the same cached iterator for the scatterlist to perform fast
sequential lookup of the dma address associated with any page within the
object.
Signed-off-by: Chris Wilson
Signed-off-by: Ankitprasad Sharma
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8a10c4b..6e54aad 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2912,6 +2912,23 @@ static inline int __sg_page_count(struct scatterlist *sg)
struct page *
i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj, int n);
+static inline dma_addr_t
+i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj, int n)
+{
+ if (n < obj->get_page.last) {
+ obj->get_page.sg = obj->pages->sgl;
+ obj->get_page.last = 0;
+ }
+
+ while (obj->get_page.last + __sg_page_count(obj->get_page.sg) <= n) {
+ obj->get_page.last += __sg_page_count(obj->get_page.sg++);
+ if (unlikely(sg_is_chain(obj->get_page.sg)))
+ obj->get_page.sg = sg_chain_ptr(obj->get_page.sg);
+ }
+
+ return sg_dma_address(obj->get_page.sg) + ((n - obj->get_page.last) <<
PAGE_SHIFT);
+}
+
static inline struct page *
i915_gem_object_get_page(struct drm_i915_gem_object *obj, int n)
{
--
1.9.1
___
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 Split driver init step to phases (rev3)
On Thu, 2016-03-17 at 14:23 +0200, Imre Deak wrote: > On Thu, 2016-03-17 at 11:32 +, Patchwork wrote: > > == Series Details == > > > > Series: Split driver init step to phases (rev3) > > URL : https://patchwork.freedesktop.org/series/4509/ > > State : warning > > > > == Summary == > > > > Series 4509v3 Split driver init step to phases > > http://patchwork.freedesktop.org/api/1.0/series/4509/revisions/3/mb > > ox > > / > > > > Test drv_module_reload_basic: > > pass -> DMESG-WARN (bsw-nuc-2) > > pass -> DMESG-WARN (skl-i5k-2) > > pass -> DMESG-WARN (bdw-ultra) > > pass -> DMESG-WARN (skl-i7k-2) > > pass -> DMESG-WARN (snb-x220t) > > pass -> DMESG-WARN (skl-nuci5) > > pass -> DMESG-WARN (bdw-nuci7) > > All the above are expected "*ERROR* failed to init modeset" messages > due to forcing init failures. I asked Tomi to filter these out if the > corresponding failure injection message precedes this error message. After discussing with Tomi and Chris the best way is to squelch the error message from the kernel in the above case, I'll follow up with a patch for this. Thanks for all the feedback and review, I pushed the patchset to -dinq. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Clearing buffer objects via CPU/GTT
From: Ankitprasad Sharma
This patch adds support for clearing buffer objects via CPU/GTT. This
is particularly useful for clearing out the non shmem backed objects.
Currently intend to use this only for buffers allocated from stolen
region.
v2: Added kernel doc for i915_gem_clear_object(), corrected/removed
variable assignments (Tvrtko)
v3: Map object page by page to the gtt if the pinning of the whole object
to the ggtt fails, Corrected function name (Chris)
v4: Clear the buffer page by page, and not map the whole object in the gtt
aperture. Use i915 wrapper function in place of drm_mm_insert_node_in_range.
v5: Use renamed wrapper function for drm_mm_insert_node_in_range,
updated barrier positioning (Chris)
v6: Use PAGE_SIZE instead of 4096, use get_pages call before pinning pages
(Tvrtko)
v7: Fixed the onion (undo operation in reverse order) (Chris)
Testcase: igt/gem_stolen
Signed-off-by: Ankitprasad Sharma
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 47 +
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6e54aad..fc21b52 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2903,6 +2903,7 @@ int i915_gem_obj_prepare_shmem_read(struct
drm_i915_gem_object *obj,
int *needs_clflush);
int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
+int i915_gem_object_clear(struct drm_i915_gem_object *obj);
static inline int __sg_page_count(struct scatterlist *sg)
{
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index caaadabb..a0116e8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5400,3 +5400,50 @@ fail:
drm_gem_object_unreference(&obj->base);
return ERR_PTR(ret);
}
+
+/**
+ * i915_gem_object_clear() - Clear buffer object via CPU/GTT
+ * @obj: Buffer object to be cleared
+ *
+ * Return: 0 - success, non-zero - failure
+ */
+int i915_gem_object_clear(struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct drm_mm_node node;
+ char __iomem *base;
+ uint64_t size = obj->base.size;
+ int ret, i;
+
+ lockdep_assert_held(&obj->base.dev->struct_mutex);
+ ret = insert_mappable_node(i915, &node, PAGE_SIZE);
+ if (ret)
+ return ret;
+
+ ret = i915_gem_object_get_pages(obj);
+ if (ret)
+ goto err_remove_node;
+
+ i915_gem_object_pin_pages(obj);
+ base = io_mapping_map_wc(i915->gtt.mappable, node.start);
+
+ for (i = 0; i < size/PAGE_SIZE; i++) {
+ i915->gtt.base.insert_page(&i915->gtt.base,
+ i915_gem_object_get_dma_address(obj,
i),
+ node.start,
+ I915_CACHE_NONE, 0);
+ wmb(); /* flush modifications to the GGTT (insert_page) */
+ memset_io(base, 0, PAGE_SIZE);
+ wmb(); /* flush the write before we modify the GGTT */
+ }
+
+ io_mapping_unmap(base);
+ i915->gtt.base.clear_range(&i915->gtt.base,
+ node.start, node.size,
+ true);
+ i915_gem_object_unpin_pages(obj);
+
+err_remove_node:
+ remove_mappable_node(&node);
+ return ret;
+}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH RESEND 4/7] drm/i915: move VBT based DSI presence check to intel_bios.c
On Wed, Mar 16, 2016 at 12:43:32PM +0200, Jani Nikula wrote:
> Hide knowledge about VBT child devices in intel_bios.c.
>
> v2: Move port check to intel_bios.c (Sivakumar)
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_bios.c | 39
> ++-
> drivers/gpu/drm/i915/intel_dsi.c | 17 -
> 3 files changed, 47 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c6ec7029f691..9c7402c062b9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1449,7 +1449,6 @@ struct intel_vbt_data {
>
> /* MIPI DSI */
> struct {
> - u16 port;
> u16 panel_id;
> struct mipi_config *config;
> struct mipi_pps_data *pps;
> @@ -3337,6 +3336,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t
> size);
> bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
> bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
> bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port);
> +bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
> *port);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 7f61ca8165f0..4b6bd6f2e193 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1237,7 +1237,6 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
> &&p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT) {
> DRM_DEBUG_KMS("Found MIPI as LFP\n");
> dev_priv->vbt.has_mipi = 1;
> - dev_priv->vbt.dsi.port = p_child->common.dvo_port;
> }
>
> child_dev_ptr = dev_priv->vbt.child_dev + count;
> @@ -1555,3 +1554,41 @@ bool intel_bios_is_port_edp(struct drm_i915_private
> *dev_priv, enum port port)
>
> return false;
> }
> +
> +/**
> + * intel_bios_is_dsi_present - is DSI present in VBT
> + * @dev_priv:i915 device instance
> + * @port:port for DSI if present
> + *
> + * Return true if DSI is present, and return the port in %port.
> + */
> +bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv,
> +enum port *port)
> +{
> + union child_device_config *p_child;
> + u8 dvo_port;
> + int i;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + p_child = dev_priv->vbt.child_dev + i;
> +
> + if (!(p_child->common.device_type & DEVICE_TYPE_MIPI_OUTPUT))
> + continue;
> +
> + dvo_port = p_child->common.dvo_port;
> +
> + switch (dvo_port) {
> + case DVO_PORT_MIPIA:
> + case DVO_PORT_MIPIC:
> + *port = dvo_port - DVO_PORT_MIPIA;
I think this needs a type cast to appease sparse. Once you've made sure
sparse is happy (i.e. with or without the cast, whatever is needed):
Reviewed-by: Daniel Vetter
> + return true;
> + case DVO_PORT_MIPIB:
> + case DVO_PORT_MIPID:
> + DRM_DEBUG_KMS("VBT has unsupported DSI port %c\n",
> + port_name(dvo_port - DVO_PORT_MIPIA));
> + break;
> + }
> + }
> +
> + return false;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 01b8e9f4c272..1df70ab9edf9 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1121,7 +1121,7 @@ void intel_dsi_init(struct drm_device *dev)
> DRM_DEBUG_KMS("\n");
>
> /* There is no detection method for MIPI so rely on VBT */
> - if (!dev_priv->vbt.has_mipi)
> + if (!intel_bios_is_dsi_present(dev_priv, &port))
> return;
>
> if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
> @@ -1162,16 +1162,15 @@ void intel_dsi_init(struct drm_device *dev)
> intel_connector->unregister = intel_connector_unregister;
>
> /* Pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI port C */
> - if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIA) {
> - intel_encoder->crtc_mask = (1 << PIPE_A);
> - intel_dsi->ports = (1 << PORT_A);
> - } else if (dev_priv->vbt.dsi.port == DVO_PORT_MIPIC) {
> - intel_encoder->crtc_mask = (1 << PIPE_B);
> - intel_dsi->ports = (1 << PORT_C);
> - }
> + if (port == PORT_A)
> + intel_encoder->crtc_mask = 1 << PIPE_A;
> + else
> + intel_encoder->crtc_mask = 1 << PIPE_B;
>
> if (dev_priv->vbt.dsi.config->dual_link)
> - intel_dsi->ports = ((1 << PORT_A) | (1 << PORT_C));
> + intel_dsi->po
Re: [Intel-gfx] [PATCH v3] prime_mmap_coherency: Add return error tests for prime sync ioctl
On 03/18/2016 03:11 PM, Daniel Vetter wrote: On Fri, Mar 18, 2016 at 03:08:56PM -0300, Tiago Vignatti wrote: This patch adds ioctl-errors subtest to be used for exercising prime sync ioctl errors. The subtest constantly interrupts via signals a function doing concurrent blit to stress out the right usage of prime_sync_*, making sure these ioctl errors are handled accordingly. Important to note that in case of failure (e.g. in a case where the ioctl wouldn't try again in a return error) this test does not reliably catch the problem with 100% of accuracy. v2: fix prime sync direction when reading mmap'ed file. v3: change the upper bound using time rather than loops Cc: Chris Wilson Signed-off-by: Tiago Vignatti I'm probably blind, but where is the reviewed kernel patch for this? If it's somewhere hidden, please resubmit with all the whizzbang stuff needed for merging added ;-) Thanks, Daniel You're not blind Daniel :) Chris will be sending the kernel side but regardless this igt test should be good to go even without the kernel patch. Tiago ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Modify reset func to handle per engine resets (rev3)
== Series Details == Series: drm/i915: Modify reset func to handle per engine resets (rev3) URL : https://patchwork.freedesktop.org/series/4510/ State : failure == Summary == Series 4510v3 drm/i915: Modify reset func to handle per engine resets http://patchwork.freedesktop.org/api/1.0/series/4510/revisions/3/mbox/ Test kms_flip: Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (hsw-brixbox) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b: pass -> DMESG-WARN (hsw-brixbox) Subgroup nonblocking-crc-pipe-c: pass -> DMESG-WARN (hsw-brixbox) Subgroup read-crc-pipe-a-frame-sequence: pass -> DMESG-WARN (bdw-ultra) bdw-nuci7total:194 pass:182 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:194 pass:172 dwarn:1 dfail:0 fail:0 skip:21 byt-nuc total:194 pass:155 dwarn:4 dfail:0 fail:0 skip:35 hsw-brixbox total:194 pass:170 dwarn:2 dfail:0 fail:0 skip:22 hsw-gt2 total:194 pass:175 dwarn:2 dfail:0 fail:0 skip:17 ivb-t430stotal:194 pass:169 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-i7k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:194 pass:183 dwarn:0 dfail:0 fail:0 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_1620/ dbbc6d276864d7b7a3a1edb04f0511153f9c3852 drm-intel-nightly: 2016y-03m-16d-22h-27m-36s UTC integration manifest 5511c10cc346289acc0ecbd55b58c2a21adc18f0 drm/i915: Modify reset func to handle per engine resets ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Release power ref after updating wm
On HSW/BDW there are random dmesg-warn errors while running kms tests, like: [90587.867077] Call Trace: [90587.867085] [] dump_stack+0x67/0x99 [90587.867094] [] warn_slowpath_common+0x81/0xc0 [90587.867099] [] warn_slowpath_fmt+0x47/0x50 [90587.867150] [] hsw_write32+0x280/0x290 [i915] [90587.867186] [] _ilk_disable_lp_wm+0x98/0xd0 [i915] [90587.867222] [] ilk_program_watermarks+0x4a2/0x940 [i915] [90587.867260] [] ilk_optimize_watermarks+0x50/0x70 [i915] [90587.867311] [] intel_atomic_commit+0x742/0x2170 [i915] [90587.867319] [] ? wait_woken+0xa0/0xa0 [90587.867326] [] drm_atomic_commit+0x32/0x50 [90587.867333] [] drm_atomic_helper_connector_dpms+0xe9/0x1a0 [90587.867340] [] drm_mode_obj_set_property_ioctl+0x21d/0x230 [90587.867346] [] drm_mode_connector_property_set_ioctl+0x2b/0x30 [90587.867352] [] drm_ioctl+0x236/0x4f0 [90587.867358] [] ? drm_mode_obj_set_property_ioctl+0x230/0x230 [90587.867366] [] do_vfs_ioctl+0x8e/0x680 [90587.867372] [] ? __fget_light+0x6a/0x90 [90587.867378] [] SyS_ioctl+0x3c/0x70 [90587.867386] [] entry_SYSCALL_64_fastpath+0x16/0x73 Since writing the watermarks requires MMIO access, this should be done before releasing the power reference. This clears the flip-flops in kms tests on HSW/BDW. Signed-off-by: Gabriel Feceoru --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ce55f0b..b141e52 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13631,9 +13631,6 @@ static int intel_atomic_commit(struct drm_device *dev, modeset_put_power_domains(dev_priv, put_domains[i]); } - if (intel_state->modeset) - intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET); - /* * Now that the vblank has passed, we can go ahead and program the * optimal watermarks on platforms that need two-step watermark @@ -13648,6 +13645,9 @@ static int intel_atomic_commit(struct drm_device *dev, dev_priv->display.optimize_watermarks(intel_cstate); } + if (intel_state->modeset) + intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET); + mutex_lock(&dev->struct_mutex); drm_atomic_helper_cleanup_planes(dev, state); mutex_unlock(&dev->struct_mutex); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: Add support for stealing purgable stolen pages
From: Chris Wilson
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous space in the vma when binding
a new object - and you will be forgiven for thinking that the code looks
very similar.
At the moment, we do not allow userspace to allocate objects in stolen,
so there is neither the memory pressure to trigger stolen eviction nor
any purgeable objects inside the stolen arena. However, this will change
in the near future, and so better management and defragmentation of
stolen memory will become a real issue.
v2: Remember to remove the drm_mm_node.
v3: Rebased to the latest drm-intel-nightly (Ankit)
v4: corrected if-else braces format (Tvrtko/kerneldoc)
v5: Rebased to the latest drm-intel-nightly (Ankit)
Added a seperate list to maintain purgable objects from stolen memory
region (Chris/Daniel)
v6: Compiler optimization (merging 2 single loops into one for() loop),
corrected code for object eviction, retire_requests before starting
object eviction (Chris)
v7: Added kernel doc for i915_gem_object_create_stolen()
v8: Check for struct_mutex lock before creating object from stolen
region (Tvrtko)
v9: Renamed variables to make usage clear, added comment, removed onetime
used macro (Tvrtko)
v10: Avoid masking of error when stolen_alloc fails (Tvrtko)
v11: Renamed stolen_link to tmp_link, as it may be used for other
purposes too (Chris)
Used ERR_CAST to cast error pointers while returning
v12: Added lockdep_assert before starting stolen-backed object
eviction (Chris)
v13: Rebased
Testcase: igt/gem_stolen
Signed-off-by: Chris Wilson
Signed-off-by: Ankitprasad Sharma
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 6 +-
drivers/gpu/drm/i915/i915_drv.h| 17 +++-
drivers/gpu/drm/i915/i915_gem.c| 15 +++
drivers/gpu/drm/i915/i915_gem_stolen.c | 171 +
drivers/gpu/drm/i915/intel_pm.c| 4 +-
5 files changed, 188 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ccdca2c..300ce9c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -172,7 +172,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
seq_puts(m, ")");
}
if (obj->stolen)
- seq_printf(m, " (stolen: %08llx)", obj->stolen->start);
+ seq_printf(m, " (stolen: %08llx)", obj->stolen->base.start);
if (obj->pin_display || obj->fault_mappable) {
char s[3], *t = s;
if (obj->pin_display)
@@ -251,9 +251,9 @@ static int obj_rank_by_stolen(void *priv,
struct drm_i915_gem_object *b =
container_of(B, struct drm_i915_gem_object, obj_exec_link);
- if (a->stolen->start < b->stolen->start)
+ if (a->stolen->base.start < b->stolen->base.start)
return -1;
- if (a->stolen->start > b->stolen->start)
+ if (a->stolen->base.start > b->stolen->base.start)
return 1;
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea87a89..4c81828 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -796,6 +796,12 @@ struct i915_ctx_hang_stats {
bool banned;
};
+struct i915_stolen_node {
+ struct drm_mm_node base;
+ struct list_head mm_link;
+ struct drm_i915_gem_object *obj;
+};
+
/* This must match up with the value previously used for execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_HANDLE 0
@@ -1243,6 +1249,13 @@ struct i915_gem_mm {
*/
struct list_head unbound_list;
+ /**
+* List of stolen objects that have been marked as purgeable and
+* thus available for reaping if we need more space for a new
+* allocation. Ordered by time of marking purgeable.
+*/
+ struct list_head stolen_list;
+
/** Usable portion of the GTT for GEM */
unsigned long stolen_base; /* limited to low memory (32-bit) */
@@ -2053,7 +2066,7 @@ struct drm_i915_gem_object {
struct list_head vma_list;
/** Stolen memory for this object, instead of being backed by shmem. */
- struct drm_mm_node *stolen;
+ struct i915_stolen_node *stolen;
struct list_head global_list;
struct list_head engine_list[I915_NUM_ENGINES];
@@ -2061,6 +2074,8 @@ struct drm_i915_gem_object {
struct list_head obj_exec_link;
struct list_head batch_pool_link;
+ /** Used to link an object to a list temporarily */
+ struct list_head tmp_link;
/**
* This is set if the object is on the active lists (has pending
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i9
Re: [Intel-gfx] [PATCH v3] drm/i915: Move CSB MMIO reads out of the execlists lock
On 17/03/16 13:14, Chris Wilson wrote:
On Thu, Mar 17, 2016 at 12:59:46PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
By reading the CSB (slow MMIO accesses) into a temporary local
buffer we can decrease the duration of holding the execlist
lock.
Main advantage is that during heavy batch buffer submission we
reduce the execlist lock contention, which should decrease the
latency and CPU usage between the submitting userspace process
and interrupt handling.
Downside is that we need to grab and relase the forcewake twice,
but as the below numbers will show this is completely hidden
by the primary gains.
Testing with "gem_latency -n 100" (submit batch buffers with a
hundred nops each) shows more than doubling of the throughput
and more than halving of the dispatch latency, overall latency
and CPU time spend in the submitting process.
Submitting empty batches ("gem_latency -n 0") does not seem
significantly affected by this change with throughput and CPU
time improving by half a percent, and overall latency worsening
by the same amount.
Above tests were done in a hundred runs on a big core Broadwell.
v2:
* Overflow protection to local CSB buffer.
* Use closer dev_priv in execlists_submit_requests. (Chris Wilson)
v3: Rebase.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 77
1 file changed, 38 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f72782200226..c6b3a9d19af2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -416,15 +416,23 @@ static void execlists_update_context(struct
drm_i915_gem_request *rq)
static void execlists_submit_requests(struct drm_i915_gem_request *rq0,
struct drm_i915_gem_request *rq1)
{
+ struct drm_i915_private *dev_priv = rq0->i915;
+
execlists_update_context(rq0);
if (rq1)
execlists_update_context(rq1);
+ spin_lock(&dev_priv->uncore.lock);
+ intel_uncore_forcewake_get__locked(dev_priv, FORCEWAKE_ALL);
My only problem with this is that it puts the onus on the caller to
remember to disable irqs first. (That would be a silent conflict with
the patch to move the submission to a kthread for example.)
Oh well in this code ones has to know what they are doing anyway so I
consider this very minor.
What's the cost of being upfront with spin_lock_irqsave() here?
No idea but probably not much if at all detectable. Issue I have with
that that elsewhere we have this approach of using the exact right one
for the use case.
/* BUG_ON(!irqs_disabled()); */ ?
As a comment?
I'm quite happy to go with the comment here and since it doesn't make
the lockups any worse,
Reviewed-by: Chris Wilsno
Thanks, will add that comment.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 03/10] drm/i915/dsi: refactor dsi get hw state readout
On Tue, Mar 15, 2016 at 09:51:11PM +0200, Jani Nikula wrote:
> Make the code easier to read and update. No functional changes.
>
> Signed-off-by: Jani Nikula
The logic looks intact
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dsi.c | 37 +++--
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 01b8e9f4c272..6574b9ac3698 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -667,7 +667,7 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
> *encoder,
> struct drm_device *dev = encoder->base.dev;
> enum intel_display_power_domain power_domain;
> enum port port;
> - bool ret;
> + bool active = false;
>
> DRM_DEBUG_KMS("\n");
>
> @@ -675,38 +675,39 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
> *encoder,
> if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> return false;
>
> - ret = false;
> -
> /* XXX: this only works for one DSI output */
> for_each_dsi_port(port, intel_dsi->ports) {
> i915_reg_t ctrl_reg = IS_BROXTON(dev) ?
> BXT_MIPI_PORT_CTRL(port) : MIPI_PORT_CTRL(port);
> - u32 dpi_enabled, func;
> -
> - func = I915_READ(MIPI_DSI_FUNC_PRG(port));
> - dpi_enabled = I915_READ(ctrl_reg) & DPI_ENABLE;
> + bool enabled = I915_READ(ctrl_reg) & DPI_ENABLE;
>
> /* Due to some hardware limitations on BYT, MIPI Port C DPI
>* Enable bit does not get set. To check whether DSI Port C
>* was enabled in BIOS, check the Pipe B enable bit
>*/
> if (IS_VALLEYVIEW(dev) && port == PORT_C)
> - dpi_enabled = I915_READ(PIPECONF(PIPE_B)) &
> - PIPECONF_ENABLE;
> + enabled = I915_READ(PIPECONF(PIPE_B)) & PIPECONF_ENABLE;
>
> - if (dpi_enabled || (func & CMD_MODE_DATA_WIDTH_MASK)) {
> - if (I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY) {
> - *pipe = port == PORT_A ? PIPE_A : PIPE_B;
> - ret = true;
> -
> - goto out;
> - }
> + /* Try command mode if video mode not enabled */
> + if (!enabled) {
> + u32 tmp = I915_READ(MIPI_DSI_FUNC_PRG(port));
> + enabled = tmp & CMD_MODE_DATA_WIDTH_MASK;
> }
> +
> + if (!enabled)
> + continue;
> +
> + if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY))
> + continue;
> +
> + *pipe = port == PORT_A ? PIPE_A : PIPE_B;
> + active = true;
> + break;
> }
> -out:
> +
> intel_display_power_put(dev_priv, power_domain);
>
> - return ret;
> + return active;
> }
>
> static void intel_dsi_get_config(struct intel_encoder *encoder,
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 8/9] drm/i915/dsi: add support for gpio elements on CHV
From: Yogesh Mohan Marimuthu
Add support for CHV gpio programming in DSI gpio elements.
XXX: I'd like to have a gpio table for chv as well as others.
[Rewritten by Jani, based on earlier work by Yogesh and Deepak.]
Signed-off-by: Yogesh Mohan Marimuthu
Signed-off-by: Deepak M
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 66 ++
1 file changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index ca48f7aa6a05..f8d3f608e9c8 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -97,6 +97,23 @@ static struct vlv_gpio_map vlv_gpio_table[] = {
{ 11, IOSF_PORT_GPIO_NC, VLV_GPIO_NC_11_PCONF0 },
};
+#define CHV_MAX_GPIO_NUM_N 72
+#define CHV_MAX_GPIO_NUM_SE99
+#define CHV_MAX_GPIO_NUM_SW197
+#define CHV_MIN_GPIO_NUM_SE73
+#define CHV_MIN_GPIO_NUM_SW100
+#define CHV_MIN_GPIO_NUM_E 198
+
+#define CHV_PAD_FMLY_BASE 0x4400
+#define CHV_PAD_FMLY_SIZE 0x400
+#define CHV_PAD_CFG_0_1_REG_SIZE 0x8
+#define CHV_PAD_CFG_REG_SIZE 0x4
+#define CHV_VBT_MAX_PINS_PER_FMLY 15
+
+#define CHV_GPIO_CFG_UNLOCK0x
+#define CHV_GPIO_CFG_HIZ 0x8100
+#define CHV_GPIO_CFG_TX_STATE_SHIFT1
+
static inline enum port intel_dsi_seq_port_to_port(u8 port)
{
return port ? PORT_C : PORT_A;
@@ -241,6 +258,53 @@ static void vlv_exec_gpio(struct drm_i915_private
*dev_priv,
mutex_unlock(&dev_priv->sb_lock);
}
+static void chv_exec_gpio(struct drm_i915_private *dev_priv,
+ u8 gpio_source, u8 gpio_index, u8 action)
+{
+ u16 pconf0, padval;
+ u16 family_num;
+ u8 port;
+
+ /* XXX: add a table similar to vlv for checking gpio indexes */
+ if (dev_priv->vbt.dsi.seq_version >= 3) {
+ if (gpio_index <= CHV_MAX_GPIO_NUM_N) {
+ port = CHV_IOSF_PORT_GPIO_N;
+ } else if (gpio_index <= CHV_MAX_GPIO_NUM_SE) {
+ port = CHV_IOSF_PORT_GPIO_SE;
+ gpio_index = gpio_index - CHV_MIN_GPIO_NUM_SE;
+ } else if (gpio_index <= CHV_MAX_GPIO_NUM_SW) {
+ port = CHV_IOSF_PORT_GPIO_SW;
+ gpio_index = gpio_index - CHV_MIN_GPIO_NUM_SW;
+ } else {
+ port = CHV_IOSF_PORT_GPIO_E;
+ gpio_index = gpio_index - CHV_MIN_GPIO_NUM_E;
+ }
+ } else if (dev_priv->vbt.dsi.seq_version == 2) {
+ if (gpio_source == 0) {
+ port = IOSF_PORT_GPIO_NC;
+ } else if (gpio_source == 1) {
+ port = IOSF_PORT_GPIO_SC;
+ } else {
+ DRM_DEBUG_KMS("unknown gpio source %u\n", gpio_source);
+ return;
+ }
+ } else {
+ port = IOSF_PORT_GPIO_NC;
+ }
+
+ family_num = gpio_index / CHV_VBT_MAX_PINS_PER_FMLY;
+ gpio_index = gpio_index - (family_num * CHV_VBT_MAX_PINS_PER_FMLY);
+ padval = CHV_PAD_FMLY_BASE + (family_num * CHV_PAD_FMLY_SIZE) +
+ (((u16)gpio_index) * CHV_PAD_CFG_0_1_REG_SIZE);
+ pconf0 = padval + CHV_PAD_CFG_REG_SIZE;
+
+ mutex_lock(&dev_priv->sb_lock);
+ vlv_iosf_sb_write(dev_priv, port, pconf0, CHV_GPIO_CFG_UNLOCK);
+ vlv_iosf_sb_write(dev_priv, port, padval, CHV_GPIO_CFG_HIZ |
+ (action << CHV_GPIO_CFG_TX_STATE_SHIFT));
+ mutex_unlock(&dev_priv->sb_lock);
+}
+
static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
{
struct drm_device *dev = intel_dsi->base.base.dev;
@@ -263,6 +327,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
*intel_dsi, const u8 *data)
if (IS_VALLEYVIEW(dev_priv))
vlv_exec_gpio(dev_priv, gpio_source, gpio_index, action);
+ else if (IS_CHERRYVIEW(dev_priv))
+ chv_exec_gpio(dev_priv, gpio_source, gpio_index, action);
else
DRM_DEBUG_KMS("GPIO element not supported on this platform\n");
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: simplify bind_to_vm init code
Hi, If we don't do any of the fence business for !i915_is_gtt, then will this not change the following code: if (alignment == 0) alignment = flags & PIN_MAPPABLE ? fence_alignment : unfenced_alignment; Or am I missing something? Regards, Matt ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/6] lib: kms: add helpers for color management properties on pipes
v2: Rename CTM_MATRIX property to CTM
v3: Add support for atomic commits
Signed-off-by: Lionel Landwerlin
---
lib/igt_kms.c | 87 +--
lib/igt_kms.h | 20 +-
2 files changed, 104 insertions(+), 3 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 515ffd0..e7ac693 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -161,7 +161,10 @@ static const char
*igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
};
static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
- "background_color"
+ "background_color",
+ "DEGAMMA_LUT",
+ "CTM",
+ "GAMMA_LUT",
};
static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
@@ -1342,6 +1345,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
for (j = 0; j < display->n_pipes; j++) {
uint64_t prop_value;
igt_pipe_t *pipe = &display->pipes[j];
+
if (output->config.crtc) {
get_crtc_property(display->drm_fd,
output->config.crtc->crtc_id,
"background_color",
@@ -1349,6 +1353,21 @@ void igt_display_init(igt_display_t *display, int drm_fd)
&prop_value,
NULL);
pipe->background = (uint32_t)prop_value;
+ get_crtc_property(display->drm_fd,
output->config.crtc->crtc_id,
+ "DEGAMMA_LUT",
+ &pipe->degamma_property,
+ NULL,
+ NULL);
+ get_crtc_property(display->drm_fd,
output->config.crtc->crtc_id,
+ "CTM",
+ &pipe->ctm_property,
+ NULL,
+ NULL);
+ get_crtc_property(display->drm_fd,
output->config.crtc->crtc_id,
+ "GAMMA_LUT",
+ &pipe->gamma_property,
+ NULL,
+ NULL);
}
}
}
@@ -1498,6 +1517,16 @@ static igt_plane_t *igt_pipe_get_plane(igt_pipe_t *pipe,
enum igt_plane plane)
return &pipe->planes[idx];
}
+bool igt_pipe_get_property(igt_pipe_t *pipe, const char *name,
+ uint32_t *prop_id, uint64_t *value,
+ drmModePropertyPtr *prop)
+{
+ return get_crtc_property(pipe->display->drm_fd,
+pipe->crtc_id,
+name,
+prop_id, value, prop);
+}
+
static uint32_t igt_plane_get_fb_id(igt_plane_t *plane)
{
if (plane->fb)
@@ -1879,6 +1908,17 @@ static int igt_output_commit(igt_output_t *output,
pipe->background_changed = false;
}
+ if (pipe->color_mgmt_changed) {
+ igt_crtc_set_property(output, pipe->degamma_property,
+ pipe->degamma_blob);
+ igt_crtc_set_property(output, pipe->ctm_property,
+ pipe->ctm_blob);
+ igt_crtc_set_property(output, pipe->gamma_property,
+ pipe->gamma_blob);
+
+ pipe->color_mgmt_changed = false;
+ }
+
for (i = 0; i < pipe->n_planes; i++) {
igt_plane_t *plane = &pipe->planes[i];
@@ -1912,10 +1952,15 @@ static void igt_atomic_prepare_crtc_commit(igt_output_t
*output, drmModeAtomicRe
if (pipe_obj->background_changed)
igt_atomic_populate_crtc_req(req, output, IGT_CRTC_BACKGROUND,
pipe_obj->background);
+ if (pipe_obj->color_mgmt_changed) {
+ igt_atomic_populate_crtc_req(req, output, IGT_CRTC_DEGAMMA_LUT,
pipe_obj->degamma_blob);
+ igt_atomic_populate_crtc_req(req, output, IGT_CRTC_CTM,
pipe_obj->ctm_blob);
+ igt_atomic_populate_crtc_req(req, output, IGT_CRTC_GAMMA_LUT,
pipe_obj->gamma_blob);
+ }
+
/*
* TODO: Add all crtc level properties here
*/
-
}
/*
@@ -2302,6 +2347,44 @@ void igt_plane_set_rotation(igt_plane_t *plane,
igt_rotation_t rotation)
plane->rotation_changed = true;
}
+static void
+igt_pipe_replace_blob(igt_pipe_t *pipe, uint64_t *blob, void *ptr, size_t
length)
+{
+ igt_display_t *display = pipe->display;
+ uint32_t blob_id = 0;
+
+ if (*blob != 0)
+ igt_assert(drmModeDestro
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)
On Wed, 16 Mar 2016 16:37:06 +0100, Daniel Vetter wrote: > > On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote: > > On Wednesday 16 March 2016 10:48:43 Imre Deak wrote: > > > Tomi, noticed two things that maybe infrastructure related, see below: > > > > > > > Test drv_module_reload_basic: > > > > skip -> PASS (bdw-nuci7) > > > > Test gem_ringfill: > > > > Subgroup basic-default-s3: > > > > pass -> DMESG-WARN (skl-nuci5) > > > > Test gem_storedw_loop: > > > > Subgroup basic-bsd: > > > > pass -> DMESG-WARN (skl-nuci5) > > > > Subgroup basic-bsd1: > > > > pass -> DMESG-WARN (skl-nuci5) > > > > > > Unrelated platform. All of the above are SND resume failures. Ville > > > said he contacted Takashi about them. > > > > SND is recurring problem. I'd like to see drm-intel-nightly not breaking > > when > > pulling sound updates. > > We need to escalate this again, snd team seriously sucks at quality > control :( Adding Libin&Takashi. If this doesn't improve I need to throw > sound trees out of -nightly for real. Sorry about that, but I couldn't get the warning on my machine. How is the procedure to reproduce the bug? Please give the exact commit id and environment you're testing, too. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/gtt: Clean up GGTT probing code
Use less pointers with the probing code, making it much less confusing
to read.
Cc: Mika Kuoppala
Reviewed-by: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 100
drivers/gpu/drm/i915/i915_gem_gtt.h | 5 +-
2 files changed, 46 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1a0f0b2..8a9fa03 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3034,20 +3034,16 @@ static void chv_setup_private_ppat(struct
drm_i915_private *dev_priv)
I915_WRITE(GEN8_PRIVATE_PAT_HI, pat >> 32);
}
-static int gen8_gmch_probe(struct drm_device *dev,
- u64 *gtt_total,
- size_t *stolen,
- phys_addr_t *mappable_base,
- u64 *mappable_end)
+static int gen8_gmch_probe(struct i915_ggtt *ggtt)
{
+ struct drm_device *dev = ggtt->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- u64 gtt_size;
u16 snb_gmch_ctl;
int ret;
/* TODO: We're not aware of mappable constraints on gen8 yet */
- *mappable_base = pci_resource_start(dev->pdev, 2);
- *mappable_end = pci_resource_len(dev->pdev, 2);
+ ggtt->mappable_base = pci_resource_start(dev->pdev, 2);
+ ggtt->mappable_end = pci_resource_len(dev->pdev, 2);
if (!pci_set_dma_mask(dev->pdev, DMA_BIT_MASK(39)))
pci_set_consistent_dma_mask(dev->pdev, DMA_BIT_MASK(39));
@@ -3055,55 +3051,51 @@ static int gen8_gmch_probe(struct drm_device *dev,
pci_read_config_word(dev->pdev, SNB_GMCH_CTRL, &snb_gmch_ctl);
if (INTEL_INFO(dev)->gen >= 9) {
- *stolen = gen9_get_stolen_size(snb_gmch_ctl);
- gtt_size = gen8_get_total_gtt_size(snb_gmch_ctl);
+ ggtt->stolen_size = gen9_get_stolen_size(snb_gmch_ctl);
+ ggtt->size = gen8_get_total_gtt_size(snb_gmch_ctl);
} else if (IS_CHERRYVIEW(dev)) {
- *stolen = chv_get_stolen_size(snb_gmch_ctl);
- gtt_size = chv_get_total_gtt_size(snb_gmch_ctl);
+ ggtt->stolen_size = chv_get_stolen_size(snb_gmch_ctl);
+ ggtt->size = chv_get_total_gtt_size(snb_gmch_ctl);
} else {
- *stolen = gen8_get_stolen_size(snb_gmch_ctl);
- gtt_size = gen8_get_total_gtt_size(snb_gmch_ctl);
+ ggtt->stolen_size = gen8_get_stolen_size(snb_gmch_ctl);
+ ggtt->size = gen8_get_total_gtt_size(snb_gmch_ctl);
}
- *gtt_total = (gtt_size / sizeof(gen8_pte_t)) << PAGE_SHIFT;
+ ggtt->base.total = (ggtt->size / sizeof(gen8_pte_t)) << PAGE_SHIFT;
if (IS_CHERRYVIEW(dev) || IS_BROXTON(dev))
chv_setup_private_ppat(dev_priv);
else
bdw_setup_private_ppat(dev_priv);
- ret = ggtt_probe_common(dev, gtt_size);
-
- dev_priv->ggtt.base.clear_range = gen8_ggtt_clear_range;
- dev_priv->ggtt.base.insert_entries = gen8_ggtt_insert_entries;
- dev_priv->ggtt.base.bind_vma = ggtt_bind_vma;
- dev_priv->ggtt.base.unbind_vma = ggtt_unbind_vma;
+ ret = ggtt_probe_common(dev, ggtt->size);
+ ggtt->base.clear_range = gen8_ggtt_clear_range;
if (IS_CHERRYVIEW(dev_priv))
- dev_priv->ggtt.base.insert_entries =
gen8_ggtt_insert_entries__BKL;
+ ggtt->base.insert_entries = gen8_ggtt_insert_entries__BKL;
+ else
+ ggtt->base.insert_entries = gen8_ggtt_insert_entries;
+ ggtt->base.bind_vma = ggtt_bind_vma;
+ ggtt->base.unbind_vma = ggtt_unbind_vma;
+
return ret;
}
-static int gen6_gmch_probe(struct drm_device *dev,
- u64 *gtt_total,
- size_t *stolen,
- phys_addr_t *mappable_base,
- u64 *mappable_end)
+static int gen6_gmch_probe(struct i915_ggtt *ggtt)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
- unsigned int gtt_size;
+ struct drm_device *dev = ggtt->base.dev;
u16 snb_gmch_ctl;
int ret;
- *mappable_base = pci_resource_start(dev->pdev, 2);
- *mappable_end = pci_resource_len(dev->pdev, 2);
+ ggtt->mappable_base = pci_resource_start(dev->pdev, 2);
+ ggtt->mappable_end = pci_resource_len(dev->pdev, 2);
/* 64/512MB is the current min/max we actually know of, but this is just
* a coarse sanity check.
*/
- if ((*mappable_end < (64<<20) || (*mappable_end > (512<<20 {
- DRM_ERROR("Unknown GMADR size (%llx)\n", *mappable_end);
+ if ((ggtt->mappable_end < (64<<20) || (ggtt->mappable_end >
(512<<20 {
+ DRM_ERROR("Unknown GMADR size (%llx)\n", ggtt->mappable_end);
return -ENXIO;
}
@@
[Intel-gfx] [PATCH 2/2] igt/gem_stolen: No support for stolen backed objects if Intel RST present
From: Ankitprasad Sharma
Skip gem_stolen and pread/pwrite on stolen backed objects if Intel
RST device is present.
Signed-off-by: Ankitprasad Sharma
---
lib/ioctl_wrappers.c | 14 +-
tests/gem_pread.c| 3 +++
tests/gem_pwrite.c | 2 ++
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 4071260..e5ee7ea 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -415,6 +415,18 @@ void gem_sync(int fd, uint32_t handle)
errno = 0;
}
+/* Is the Intel RST device present */
+#define RST_PATH "/sys/bus/acpi/devices/INT3392:00"
+
+static bool is_rst_present(void)
+{
+ struct stat st;
+
+ if (stat(RST_PATH, &st) == 0)
+ return true;
+
+ return false;
+}
bool gem_create__has_stolen_support(int fd)
{
@@ -429,7 +441,7 @@ bool gem_create__has_stolen_support(int fd)
/* Do we have the extended gem_create_ioctl? */
ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp);
- has_stolen_support = val >= 2;
+ has_stolen_support = val >= 2 && !is_rst_present();
}
return has_stolen_support;
diff --git a/tests/gem_pread.c b/tests/gem_pread.c
index afa072d..f4cf472 100644
--- a/tests/gem_pread.c
+++ b/tests/gem_pread.c
@@ -152,6 +152,7 @@ int main(int argc, char **argv)
}
igt_subtest("stolen-normal") {
+ gem_require_stolen_support(fd);
for (count = 1; count <= 1<<17; count <<= 1) {
struct timeval start, end;
@@ -167,6 +168,7 @@ int main(int argc, char **argv)
}
for (c = cache; c->level != -1; c++) {
igt_subtest_f("stolen-%s", c->name) {
+ gem_require_stolen_support(fd);
gem_set_caching(fd, src_stolen, c->level);
for (count = 1; count <= 1<<17; count <<= 1) {
@@ -190,6 +192,7 @@ int main(int argc, char **argv)
* user space buffer
*/
igt_subtest("pagefault-pread") {
+ gem_require_stolen_support(fd);
large_stolen = gem_create_stolen(fd, LARGE_OBJECT_SIZE);
stolen_nopf_user = (uint32_t *) mmap(NULL, LARGE_OBJECT_SIZE,
PROT_WRITE,
diff --git a/tests/gem_pwrite.c b/tests/gem_pwrite.c
index 42206d7..5d99b29 100644
--- a/tests/gem_pwrite.c
+++ b/tests/gem_pwrite.c
@@ -206,6 +206,7 @@ int main(int argc, char **argv)
}
igt_subtest("stolen-normal") {
+ gem_require_stolen_support(fd);
for (count = 1; count <= 1<<17; count <<= 1) {
struct timeval start, end;
@@ -222,6 +223,7 @@ int main(int argc, char **argv)
}
for (c = cache; c->level != -1; c++) {
+ gem_require_stolen_support(fd);
igt_subtest_f("stolen-%s", c->name) {
gem_set_caching(fd, dst, c->level);
for (count = 1; count <= 1<<17; count <<= 1) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix eDP low vswing for Broadwell
On Thu, Mar 17, 2016 at 12:23:10PM +0200, Mika Kahola wrote:
> It was noticed on bug #94087 that module parameter
> i915.edp_vswing=2 that should override the VBT setting
> to use default voltage swing (400 mV) was not applied
> for Broadwell.
>
> This patch provides a fix for this by checking if default
> i.e. higher voltage swing is requested to be used and
> applies the DDI translations table for DP instead of eDP
> (low vswing) table.
The spec is rather vague on the matter. For BDW it just lists the tables
as "for DisplayPort" and "for embedded DisplayPort rev 1.4", whereas SKL
has them as "for DisplayPort" and "for embedded DisplayPorts that support
low voltage swings". But looking at the details, it's clear that the BDW
eDP table is really a low vswing table.
The VBT spec has nothing to say beyond the fact that the low vswing
option was added in version 173 (which we already handle correctly).
So the patch is
Reviewed-by: Ville Syrjälä
>
> v2: Combine two if statements into one (Jani)
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ab025a5..100a532 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -443,9 +443,17 @@ void intel_prepare_ddi_buffer(struct intel_encoder
> *encoder)
> } else if (IS_BROADWELL(dev_priv)) {
> ddi_translations_fdi = bdw_ddi_translations_fdi;
> ddi_translations_dp = bdw_ddi_translations_dp;
> - ddi_translations_edp = bdw_ddi_translations_edp;
> +
> + if (dev_priv->edp_low_vswing) {
> + ddi_translations_edp = bdw_ddi_translations_edp;
> + n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> + } else {
> + ddi_translations_edp = bdw_ddi_translations_dp;
> + n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> + }
> +
> ddi_translations_hdmi = bdw_ddi_translations_hdmi;
> - n_edp_entries = ARRAY_SIZE(bdw_ddi_translations_edp);
> +
> n_dp_entries = ARRAY_SIZE(bdw_ddi_translations_dp);
> n_hdmi_entries = ARRAY_SIZE(bdw_ddi_translations_hdmi);
> hdmi_default_entry = 7;
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] lib: Add igt_subtest_group
Useful for creating common setup code in igt_fixture which is only
needed by a subset of tests. And since I'm a good citizen it comes
with a library testcase/example included.
v2: Make testcase nastier to ensure a subtest group SKIPS when it's
parent is skipping already. I accidentally got this right, but let's
make sure.
Signed-off-by: Daniel Vetter
---
NEWS | 6 +
lib/igt_core.c| 14 +-
lib/igt_core.h| 24 +
lib/tests/.gitignore | 1 +
lib/tests/Makefile.sources| 1 +
lib/tests/igt_subtest_group.c | 63 +++
6 files changed, 108 insertions(+), 1 deletion(-)
create mode 100644 lib/tests/igt_subtest_group.c
diff --git a/NEWS b/NEWS
index a42382f3f6d3..6a3fac77a4d9 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,9 @@
+Release 1.15 (-XX-XX)
+-
+
+- Add igt_subtest_group to allow igt_fixture for only a subset of subtests
+ without skipping/failing all subsequent subtests.
+
Release 1.14 (2016-03-01)
-
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 3c092a5f1651..947a9ca37690 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -97,7 +97,9 @@
*
* To allow this i-g-t provides #igt_fixture code blocks for setup code outside
* of subtests and automatically skips the subtest code blocks themselves. For
- * special cases igt_only_list_subtests() is also provided.
+ * special cases igt_only_list_subtests() is also provided. For setup code only
+ * shared by a group of subtest encapsulate the #igt_fixture block and all the
+ * subtestest in a #igt_subtest_group block.
*
* # Magic Control Blocks
*
@@ -889,6 +891,16 @@ bool igt_only_list_subtests(void)
return list_subtests;
}
+void __igt_subtest_group_save(int *save)
+{
+ *save = skip_subtests_henceforth;
+}
+
+void __igt_subtest_group_restore(int save)
+{
+ skip_subtests_henceforth = save;
+}
+
static bool skipped_one = false;
static bool succeeded_one = false;
static bool failed_one = false;
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 124ae0d90f2f..b3fa7356e473 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -197,6 +197,30 @@ bool __igt_run_subtest(const char *subtest_name);
const char *igt_subtest_name(void);
bool igt_only_list_subtests(void);
+void __igt_subtest_group_save(int *);
+void __igt_subtest_group_restore(int);
+/**
+ * igt_subtest_group:
+ *
+ * Group a set of subtests together with their common setup code
+ *
+ * Testcase with subtests often need to set up a bunch of shared state as the
+ * common test fixture. But if there are multiple with different requirements
+ * the commont setup code can't be extracted, since a test condition failure in
+ * e.g. igt_require() would result in all subsequent tests skipping. Even those
+ * from a different group.
+ *
+ * This macro allows to group together a set of #igt_fixture and #igt_subtest
+ * clauses. If any common setup in a fixture fails, only the subtests in this
+ * group will fail or skip. Subtest groups can be arbitrarily nested.
+ */
+#define igt_subtest_group for (int igt_tokencat(__tmpint,__LINE__) = 0, \
+ igt_tokencat(__save,__LINE__) = 0; \
+ igt_tokencat(__tmpint,__LINE__) < 1 && \
+ (__igt_subtest_group_save(&
igt_tokencat(__save,__LINE__) ), true); \
+ igt_tokencat(__tmpint,__LINE__) ++, \
+
__igt_subtest_group_restore(igt_tokencat(__save,__LINE__) ))
+
/**
* igt_main:
*
diff --git a/lib/tests/.gitignore b/lib/tests/.gitignore
index 661386a38dc8..842482c0a12c 100644
--- a/lib/tests/.gitignore
+++ b/lib/tests/.gitignore
@@ -11,4 +11,5 @@ igt_segfault
igt_simple_test_subtests
igt_simulation
igt_stats
+igt_subtest_group
igt_timeout
diff --git a/lib/tests/Makefile.sources b/lib/tests/Makefile.sources
index 09baeb127d22..707c445afca6 100644
--- a/lib/tests/Makefile.sources
+++ b/lib/tests/Makefile.sources
@@ -10,6 +10,7 @@ check_PROGRAMS = \
igt_timeout \
igt_invalid_subtest_name \
igt_segfault \
+ igt_subtest_group \
igt_assert \
igt_exit_handler \
$(NULL)
diff --git a/lib/tests/igt_subtest_group.c b/lib/tests/igt_subtest_group.c
new file mode 100644
index ..2b17955c5ac8
--- /dev/null
+++ b/lib/tests/igt_subtest_group.c
@@ -0,0 +1,63 @@
+/*
+ * 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:
+ *
+
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Set GPU freq to idle_freq initially
On Fri, 2016-03-04 at 21:43 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we set the initial GPU frequency to min_freq_softlimit
> on gen9, and to efficient_freq on VLV/CHV. On all the other platforms
> we set it to idle_freq. Let's use idle_freq across the board to make
> sure we don't waste power. This is especially relevant for VLV since
> Vnn won't drop to minimum unless the GPU is at the minimum frequency.
>
> Signed-off-by: Ville Syrjälä
Yes, I think having the same logic on all platforms make sense, so:
Reviewed-by: Imre Deak
I noticed that rps.min_freq is always the same as rps.idle_freq, what's
the reason to have both, could we remove one of them? Adding Chris.
> ---
> drivers/gpu/drm/i915/intel_pm.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index c53b8c4d381c..2591d533a895 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -4804,7 +4804,7 @@ static void gen9_enable_rps(struct drm_device *dev)
> * Up/Down EI & threshold registers, as well as the RP_CONTROL,
> * RP_INTERRUPT_LIMITS & RPNSWREQ registers */
> dev_priv->rps.power = HIGH_POWER; /* force a reset */
> - gen6_set_rps(dev_priv->dev, dev_priv->rps.min_freq_softlimit);
> + gen6_set_rps(dev_priv->dev, dev_priv->rps.idle_freq);
>
> intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> }
> @@ -5594,10 +5594,10 @@ static void cherryview_enable_rps(struct drm_device
> *dev)
> dev_priv->rps.cur_freq);
>
> DRM_DEBUG_DRIVER("setting GPU freq to %d MHz (%u)\n",
> - intel_gpu_freq(dev_priv, dev_priv->rps.efficient_freq),
> - dev_priv->rps.efficient_freq);
> + intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq),
> + dev_priv->rps.idle_freq);
>
> - valleyview_set_rps(dev_priv->dev, dev_priv->rps.efficient_freq);
> + valleyview_set_rps(dev_priv->dev, dev_priv->rps.idle_freq);
>
> intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> }
> @@ -5684,10 +5684,10 @@ static void valleyview_enable_rps(struct drm_device
> *dev)
> dev_priv->rps.cur_freq);
>
> DRM_DEBUG_DRIVER("setting GPU freq to %d MHz (%u)\n",
> - intel_gpu_freq(dev_priv, dev_priv->rps.efficient_freq),
> - dev_priv->rps.efficient_freq);
> + intel_gpu_freq(dev_priv, dev_priv->rps.idle_freq),
> + dev_priv->rps.idle_freq);
>
> - valleyview_set_rps(dev_priv->dev, dev_priv->rps.efficient_freq);
> + valleyview_set_rps(dev_priv->dev, dev_priv->rps.idle_freq);
>
> intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 13/19] drm/i915: Move unload time opregion unregistration earlier
Move the opregion unregistration earlier to match its corresponding registration order. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/i915_dma.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 7ab8ac5..e2465c6 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1222,6 +1222,7 @@ int i915_driver_unload(struct drm_device *dev) i915_teardown_sysfs(dev); acpi_video_unregister(); + intel_opregion_fini(dev); i915_gem_shrinker_cleanup(dev_priv); drm_vblank_cleanup(dev); @@ -1251,8 +1252,6 @@ int i915_driver_unload(struct drm_device *dev) cancel_delayed_work_sync(&dev_priv->gpu_error.hangcheck_work); i915_destroy_error_state(dev); - intel_opregion_fini(dev); - /* Flush any outstanding unpin_work. */ flush_workqueue(dev_priv->wq); -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] tests/gem_concurrent_blt|all: Use igt_subtest_group
Looks tidy again, and doesn't break igt assumptions.
Signed-off-by: Daniel Vetter
---
tests/gem_concurrent_all.c | 67 +-
1 file changed, 30 insertions(+), 37 deletions(-)
diff --git a/tests/gem_concurrent_all.c b/tests/gem_concurrent_all.c
index 67c9a4a2f71a..64d252087fb6 100644
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -814,12 +814,6 @@ static void buffers_create(struct buffers *b)
int count = b->num_buffers;
igt_assert(b->bufmgr);
- if (b->create->require)
- b->create->require(b->create);
-
- if (b->mode->require)
- b->mode->require(b->create);
-
intel_require_memory(2*count, 4*b->npixels, b->allow_mem);
buffers_destroy(b);
@@ -1446,27 +1440,29 @@ run_basic_modes(const char *prefix,
for (p = all ? pipelines : pskip; p->prefix; p++) {
struct buffers buffers;
- igt_fixture
+ /* No nesting to avoid this looking ridiculous. */
+ igt_subtest_group {
+
+ igt_fixture {
buffers_init(&buffers, prefix, create, mode,
size, num_buffers, allow_mem,
fd, run_wrap_func != run_child);
+ p->require();
+ }
igt_subtest_f("%s-%s-%s-sanitycheck0%s%s", prefix,
mode->name, p->prefix, suffix, h->suffix) {
- p->require();
buffers_create(&buffers);
run_wrap_func(&buffers, do_basic0,
p->copy, h->hang);
}
igt_subtest_f("%s-%s-%s-sanitycheck1%s%s", prefix,
mode->name, p->prefix, suffix, h->suffix) {
- p->require();
buffers_create(&buffers);
run_wrap_func(&buffers, do_basic1,
p->copy, h->hang);
}
igt_subtest_f("%s-%s-%s-sanitycheckN%s%s", prefix,
mode->name, p->prefix, suffix, h->suffix) {
- p->require();
buffers_create(&buffers);
run_wrap_func(&buffers, do_basicN,
p->copy, h->hang);
@@ -1474,7 +1470,6 @@ run_basic_modes(const char *prefix,
/* try to overwrite the source values */
igt_subtest_f("%s-%s-%s-overwrite-source-one%s%s",
prefix, mode->name, p->prefix, suffix, h->suffix) {
- p->require();
buffers_create(&buffers);
run_wrap_func(&buffers,
do_overwrite_source__one,
@@ -1482,7 +1477,6 @@ run_basic_modes(const char *prefix,
}
igt_subtest_f("%s-%s-%s-overwrite-source%s%s", prefix,
mode->name, p->prefix, suffix, h->suffix) {
- p->require();
buffers_create(&buffers);
run_wrap_func(&buffers,
do_overwrite_source,
@@ -1490,7 +1484,6 @@ run_basic_modes(const char *prefix,
}
igt_subtest_f("%s-%s-%s-overwrite-source-read-bcs%s%s",
prefix, mode->name, p->prefix, suffix, h->suffix) {
- p->require();
buffers_create(&buffers);
run_wrap_func(&buffers,
do_overwrite_source_read_bcs,
@@ -1498,7 +1491,6 @@ run_basic_modes(const char *prefix,
}
igt_subtest_f("%s-%s-%s-overwrite-source-read-rcs%s%s",
prefix, mode->name, p->prefix, suffix, h->suffix) {
- p->require();
igt_require(rendercopy);
buffers_create(&buffers);
run_wrap_func(&buffers,
@@ -1507,7 +1499,6 @@ run_basic_modes(const char *prefix,
}
igt_subtest_f("%s-%s-%s-overwrite-source-rev%s%s",
prefix, mode->name, p->prefix, suffix, h->suffix) {
- p->require();
buffers_create(&buffers);
run_wrap_func(&buffers,
do_overwrite_source__rev,
@@ -1516,7 +1507,6 @@ run_basic_modes(const char *prefix,
/* try to intermix copies with GPU copies*/
i
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)
On Fri, 18 Mar 2016 08:36:27 +0100, Tomi Sarvela wrote: > > On Thursday 17 March 2016 18:00:52 Takashi Iwai wrote: > ... > > > > CI_DRM_1147 git://anongit.freedesktop.org/drm-intel > > > dbbc6d276864d7b7a3a1edb04f0511153f9c3852 > > > > > > Note that drm-intel-nightly history changes, so the exact commits might > > > not be there any more. > > > > Well, I have no internal access, so I have no idea which one succeeded > > and which one failed. > > > > Unfortunately I can't reproduce it in my side. A simpler unit test > > that can reliably reproduce the issue would be really appreciated... > > Sorry, I was being unclear. They all fail on selected machines (ILK, SNB), > since CI_DRM_1140. Do you have the commit of the last working kernel? > The unit tests that hang quite reliably on first run are > igt@gem_ringfill_basic-default-s3 > igt@drv_module_reload_basic > igt@kms_pipe_crc_basic@suspend-read-crc-pipe-[abc] Where can I get these? Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V11] drm/i915/skl: SKL CDCLK change on modeset tracking VCO
On Wed, Mar 16, 2016 at 4:33 PM Clint Taylor
wrote:
> On 03/16/2016 12:27 AM, Daniel Vetter wrote:
> > On Tue, Mar 15, 2016 at 02:34:05PM -0700, clinton.a.tay...@intel.com
> wrote:
> >> From: Clint Taylor
> >>
> >> WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor
> connected
> >> to DDI1 the system will hard hang during a cold boot. Occurs when DDI1
> >> is enabled when the cdclk is less then required. DP connected to DDI2
> >> and HPD on either port works correctly.
> >
> > So this patch hard-hangs machines?
>
> The hard-hang only occurs in developer mode ChromeOS with Coreboot (FSP
> version < 1.9) using DP on DDI1 using a USB-C->DP converter.
>
> We have not been able to reproduce this issue since updating to FSP 1.9
> and was never able to replicate the issue with UEFI and SKL RVP. The
> warning was added to the commit message during development to make
> everyone aware of the issue.
>
What does this developer mode has special/different?
What are the risks of getting this in other platform out there non chrome?
>
> >
> >>
> >> Set cdclk based on the max required pixel clock based on VCO
> >> selected. Track boot vco instead of boot cdclk.
> >>
> >> The vco is now tracked at the atomic level and all CRTCs updated if
> >> the required vco is changed. Not tested with eDP v1.4 panels that
> >> require 8640 vco due to availability.
> >>
> >> V1: initial version
> >> V2: add vco tracking in intel_dp_compute_config(), rename
> >> skl_boot_cdclk.
> >> V3: rebase, V2 feedback not possible as encoders are not aware of
> >> atomic.
> >> V4: track target vco is atomic state. modeset all CRTCs if vco changes
> >> V5: rename atomic variable, cleaner if/else logic, use existing vco if
> >>encoder does not return a new vco value. check_patch.pl cleanup
> >> V6: simplify logic in intel_modeset_checks.
> >> V7: reorder an IF for readability and whitespace fix.
> >> V8: use dev_cdclk for tracking new cdclk during atomic
> >> V9: correctly handle vco 8640 when crtcs==0
> >> V10: Clean up if else in crtcs==0
> >> V11: Rebase for new intel_dpll_mgr.c
> >>
> >> Reviewed-by: Ville Syrjälä
> >
> > Is the r-b from Ville really for v11?
>
> r-b is from patch V9 and only his V8 comment change and a rebase has
> occured since. I will submit a V12 with the warning and r-b removed if
> necessary.
>
Ville?
>
> > -Daniel
> >
> >> Signed-off-by: Clint Taylor
> >> ---
> >> drivers/gpu/drm/i915/i915_drv.h |2 +-
> >> drivers/gpu/drm/i915/intel_display.c | 111
> -
> >> drivers/gpu/drm/i915/intel_dpll_mgr.c |9 +--
> >> drivers/gpu/drm/i915/intel_drv.h |5 ++
> >> 4 files changed, 106 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 80b14f1..bf87e62 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -1759,7 +1759,7 @@ struct drm_i915_private {
> >> int num_fence_regs; /* 8 on pre-965, 16 otherwise */
> >>
> >> unsigned int fsb_freq, mem_freq, is_ddr3;
> >> -unsigned int skl_boot_cdclk;
> >> +unsigned int skl_vco_freq;
> >> unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
> >> unsigned int max_dotclk_freq;
> >> unsigned int rawclk_freq;
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> >> index ce55f0b..fc5268c 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -5584,7 +5584,7 @@ static unsigned int skl_cdclk_decimal(unsigned
> int freq)
> >> return (freq - 1000) / 500;
> >> }
> >>
> >> -static unsigned int skl_cdclk_get_vco(unsigned int freq)
> >> +unsigned int skl_cdclk_get_vco(unsigned int freq)
> >> {
> >> unsigned int i;
> >>
> >> @@ -5742,17 +5742,21 @@ void skl_uninit_cdclk(struct drm_i915_private
> *dev_priv)
> >>
> >> void skl_init_cdclk(struct drm_i915_private *dev_priv)
> >> {
> >> -unsigned int required_vco;
> >> +unsigned int cdclk;
> >>
> >> /* DPLL0 not enabled (happens on early BIOS versions) */
> >> if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
> >> /* enable DPLL0 */
> >> -required_vco = skl_cdclk_get_vco(dev_priv->skl_boot_cdclk);
> >> -skl_dpll0_enable(dev_priv, required_vco);
> >> +if (dev_priv->skl_vco_freq != 8640)
> >> +dev_priv->skl_vco_freq = 8100;
> >> +skl_dpll0_enable(dev_priv, dev_priv->skl_vco_freq);
> >> +cdclk = ((dev_priv->skl_vco_freq == 8100) ? 337500 :
> 308570);
> >> +} else {
> >> +cdclk = dev_priv->cdclk_freq;
> >> }
> >>
> >> -/* set CDCLK to the frequency the BIOS chose */
> >> -skl_set_cdclk(dev_priv, dev_priv->skl_boot_cdclk);
> >> +/* set CDCLK to the lowest frequency, Modeset follows */
> >> +skl_set_cdclk(dev_priv, cdclk);
> >>
> >> /* enable D
[Intel-gfx] [PATCH v3 00/19] Split driver init step to phases
This is v3 of [1]. It includes now the fault injection patches Chris requested and addresses comments from Daniel and Joonas. Since IGT has by now an updated drv_module_reload_basic too using load failure injection, CI hopefully catches any problems introduced by this patchset. CC: Chris Wilson CC: Jani Nikula CC: Ander Conselvan de Oliveira CC: Joonas Lahtinen CC: Daniel Vetter [1] https://lists.freedesktop.org/archives/intel-gfx/2016-March/089596.html Imre Deak (19): Fix MCHBAR cleanup on the driver init error path drm/i915: Move load time PCH detect, DPIO, power domain SW init earlier drm/i915: Move load time IRQ SW init earlier drm/i915: Move load time init of display/audio hooks earlier drm/i915: Move load time init of clock gating hooks earlier drm/i915: Move load time runtime device info init earlier drm/i915: Move load time gem_load_init earlier drm/i915: Move load time runtime PM get later drm/i915: Move load time shrinker registration later drm/i915: Move load time audio component registration earlier drm/i915: Move unload time display power domain uninit later drm/i915: Move unload time GTT, MSI IRQ cleanup later drm/i915: Move unload time opregion unregistration earlier drm/i915: Split out load time early initialization drm/i915: Split out load time MMIO initialization drm/i915: Split out load time HW initialization drm/i915: Split out load time interface registration drm/i915: Fix power domain HW state cleanup on error path drm/i915: Add fault injection support drivers/gpu/drm/i915/i915_dma.c | 399 --- drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 34 +-- drivers/gpu/drm/i915/i915_irq.c | 2 - drivers/gpu/drm/i915/i915_params.c | 5 + drivers/gpu/drm/i915/i915_params.h | 1 + drivers/gpu/drm/i915/intel_audio.c | 16 +- drivers/gpu/drm/i915/intel_display.c | 82 --- drivers/gpu/drm/i915/intel_drv.h | 4 +- drivers/gpu/drm/i915/intel_pm.c | 91 +--- 10 files changed, 409 insertions(+), 230 deletions(-) -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Intel Atom SoC Bay/Cherry Trail - HDMI Audio
... meanwhile ...
$ modinfo hdmi_audio
filename:
/lib/modules/4.5.0-301.fc22.x86_64/kernel/sound/hdmi_audio/hdmi_audio.ko.xz
version:0.01.003
license:GPL v2
description:Intel HDMI Audio driver
author: Vaibhav Agarwal
author: Ramesh Babu K V
author: Sailaja Bandarupalli
srcversion: 3AA3766F4433DC0AC4234C3
alias: acpi*:HAD022A8:*
alias: acpi*:HAD0F28:*
depends:snd-pcm,i915,snd
intree: Y
vermagic: 4.5.0-301.fc22.x86_64 SMP mod_unload
parm: hdmi_card_index:Index value for INTEL Intel HDMI Audio
controller. (int)
parm: hdmi_card_id:ID string for INTEL Intel HDMI Audio controller.
(charp)
$ dmesg ...
had: HAD DRIVER loading.. Ver: 0.01.003
HDMI Audio support on Atom w/o HDAUdio
w/ kernel-modules-4.5.0-301.fc22.x86_64
https://patchwork.freedesktop.org/series/4142/
https://kojipkgs.fedoraproject.org/packages/kernel/4.5.0/300.fc24/src/
---
...15-changes-for-non-HDAudio-HDMI-interface.patch | 27 +++---
...elated-changes-non-HDAudio-HDMI-interface.patch | 8 +++
...-Atom-add-Atom-non-HDAudio-HDMI-interface.patch | 15 ++--
RFC-10-15-add-dependency-on-PM_RUNTIME.patch | 12 +-
config-generic | 1 +
5 files changed, 32 insertions(+), 31 deletions(-)
diff --git a/RFC-05-15-drm-i915-changes-for-non-HDAudio-HDMI-interface.patch
b/RFC-05-15-drm-i915-changes-for-non-HDAudio-HDMI-interface.patch
index fca2f41..2446dc2 100644
--- a/RFC-05-15-drm-i915-changes-for-non-HDAudio-HDMI-interface.patch
+++ b/RFC-05-15-drm-i915-changes-for-non-HDAudio-HDMI-interface.patch
@@ -3,7 +3,7 @@ diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index d1a46ef..556fa80 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
-@@ -603,6 +603,31 @@ i915_disable_pipestat(struct drm_i915_private *dev_priv,
enum pipe pipe,
+@@ -603,6 +603,31 @@
__i915_disable_pipestat(dev_priv, pipe, enable_mask, status_mask);
}
@@ -35,15 +35,15 @@ index d1a46ef..556fa80 100644
/**
* i915_enable_asle_pipestat - enable ASLE pipestat for OpRegion
* @dev: drm device
-@@ -1649,6 +1674,7 @@ static void valleyview_pipestat_irq_handler(struct
drm_device *dev, u32 iir)
+@@ -1649,6 +1674,7 @@
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pipe_stats[I915_MAX_PIPES] = { };
int pipe;
+ int lpe_stream;
spin_lock(&dev_priv->irq_lock);
-
-@@ -1719,6 +1745,24 @@ static void valleyview_pipestat_irq_handler(struct
drm_device *dev, u32 iir)
+ for_each_pipe(dev_priv, pipe) {
+@@ -1713,6 +1739,24 @@
intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
}
@@ -68,7 +68,7 @@ index d1a46ef..556fa80 100644
if (pipe_stats[0] & PIPE_GMBUS_INTERRUPT_STATUS)
gmbus_irq_handler(dev);
}
-@@ -2804,6 +2848,43 @@ static void gen8_disable_vblank(struct drm_device *dev,
unsigned int pipe)
+@@ -2790,6 +2834,43 @@
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
}
@@ -135,7 +135,7 @@ diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi
index 1beb155..8b6c31a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
-@@ -1391,6 +1391,124 @@ intel_hdmi_set_edid(struct drm_connector *connector,
bool force)
+@@ -1386,6 +1386,124 @@
return connected;
}
@@ -260,7 +260,7 @@ index 1beb155..8b6c31a 100644
static enum drm_connector_status
intel_hdmi_detect(struct drm_connector *connector, bool force)
{
-@@ -1399,6 +1517,8 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
+@@ -1394,6 +1512,8 @@
struct drm_i915_private *dev_priv = to_i915(connector->dev);
bool live_status = false;
unsigned int try;
@@ -269,7 +269,7 @@ index 1beb155..8b6c31a 100644
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
-@@ -1427,6 +1547,26 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
+@@ -1422,6 +1542,26 @@
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
@@ -296,7 +296,7 @@ index 1beb155..8b6c31a 100644
return status;
}
-@@ -1450,12 +1590,22 @@ intel_hdmi_force(struct drm_connector *connector)
+@@ -1445,12 +1585,22 @@
static int intel_hdmi_get_modes(struct drm_connector *connector)
{
struct edid *edid;
@@ -320,7 +320,7 @@ index 1beb155..8b6c31a 100644
}
static bool
-@@ -2159,6 +2309,20 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,
+@@ -2149,6 +2299,20 @@
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
@@ -341,17 +341,18 @@ index 1beb155..8b6c31a 100644
}
void intel_hdmi_init(struct drm_device *dev,
-@@ -2168,6 +2332,8 @@ void intel_
Re: [Intel-gfx] [PATCH] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
On Fri, Mar 18, 2016 at 08:02:39PM +, Chris Wilson wrote:
> Drivers, especially i915.ko, can fail during the initial migration of a
> dma-buf for CPU access. However, the error code from the driver was not
> being propagated back to ioctl and so userspace was blissfully ignorant
> of the failure. Rendering corruption ensues.
>
> Whilst fixing the ioctl to return the error code from
> dma_buf_start_cpu_access(), also do the same for
> dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
> cannot fail. i915.ko however, as most drivers would, wants to avoid being
> uninterruptible (as would be required to guarrantee no failure when
> flushing the buffer to the device). As userspace already has to handle
> errors from the SYNC_IOCTL, take advantage of this to be able to restart
> the syscall across signals.
>
> This fixes a coherency issue for i915.ko as well as reducing the
> uninterruptible hold upon its BKL, the struct_mutex.
>
> Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
> Author: Daniel Vetter
> Date: Thu Feb 11 20:04:51 2016 -0200
>
> dma-buf: Add ioctls to allow userspace to flush
>
> Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
> Testcase: igt/prime_mmap_coherency/ioctl-errors
> Signed-off-by: Chris Wilson
> Cc: Tiago Vignatti
> Cc: Stéphane Marchesin
> Cc: David Herrmann
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> CC: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: de...@driverdev.osuosl.org
Applied to drm-misc, I'll send a pull to Dave the next few days if no one
screams.
-Daniel
> ---
> drivers/dma-buf/dma-buf.c | 17 +++--
> drivers/gpu/drm/i915/i915_gem_dmabuf.c| 15 +--
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 5 +++--
> drivers/gpu/drm/udl/udl_fb.c | 4 ++--
> drivers/staging/android/ion/ion.c | 6 --
> include/linux/dma-buf.h | 6 +++---
> 6 files changed, 28 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 9810d1df0691..774a60f4309a 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file,
> struct dma_buf *dmabuf;
> struct dma_buf_sync sync;
> enum dma_data_direction direction;
> + int ret;
>
> dmabuf = file->private_data;
>
> @@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file,
> }
>
> if (sync.flags & DMA_BUF_SYNC_END)
> - dma_buf_end_cpu_access(dmabuf, direction);
> + ret = dma_buf_end_cpu_access(dmabuf, direction);
> else
> - dma_buf_begin_cpu_access(dmabuf, direction);
> + ret = dma_buf_begin_cpu_access(dmabuf, direction);
>
> - return 0;
> + return ret;
> default:
> return -ENOTTY;
> }
> @@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
> *
> * This call must always succeed.
> */
> -void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> - enum dma_data_direction direction)
> +int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> +enum dma_data_direction direction)
> {
> + int ret = 0;
> +
> WARN_ON(!dmabuf);
>
> if (dmabuf->ops->end_cpu_access)
> - dmabuf->ops->end_cpu_access(dmabuf, direction);
> + ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index 1f3eef6fb345..0506016e18e0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -228,25 +228,20 @@ static int i915_gem_begin_cpu_access(struct dma_buf
> *dma_buf, enum dma_data_dire
> return ret;
> }
>
> -static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
> dma_data_direction direction)
> +static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
> dma_data_direction direction)
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_device *dev = obj->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - bool was_interruptible;
> int ret;
>
> - mutex_lock(&dev->struct_mutex);
> - was_interruptible = dev_priv->mm.interruptible;
> - dev_priv->mm.interruptible = false;
> + ret = i915_mutex_lock_interruptible(dev);
> + if (ret)
> + return ret;
>
> ret = i915_gem_object_set_to_gtt_domain(obj, false);
> -
> - dev_priv->mm.interruptible = was_interruptible;
> mutex_unlock(&dev->struct_mutex);
>
> - if (unlikely(ret))
> - DRM_E
[Intel-gfx] [maintainer-tools PATCH] dim: turn commit-add-tag into a proper dim subcommand
This lets you add e.g. review tags to a commit on the command line:
$ dim commit-add-tag "Reviewed-by: Ville Syrjälä
"
This could be used as a building block for further scripting.
Signed-off-by: Jani Nikula
---
dim | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/dim b/dim
index 9c8ae1098977..eda79017be94 100755
--- a/dim
+++ b/dim
@@ -183,15 +183,16 @@ if message_id is not None:
EOF
}
-# append a new tag at the end of the commit message of HEAD
-# $1 = tag, $2 = value
-commit_add_tag ()
+# append all arguments as tags at the end of the commit message of HEAD
+function dim_commit_add_tag
{
- # the first sed deletes all trailing blank lines at the end
- git log -1 --pretty=%B | \
- sed -e :a -e '/^\n*$/{$d;N;ba' -e '}' | \
- sed "\$a$1: $2" | \
- git commit --amend -F-
+ for arg; do
+ # the first sed deletes all trailing blank lines at the end
+ git log -1 --pretty=%B | \
+ sed -e :a -e '/^\n*$/{$d;N;ba' -e '}' | \
+ sed "\$a${arg}" | \
+ git commit --amend -F-
+ done
}
function update_linux_next
@@ -427,7 +428,7 @@ function dim_apply_branch
cat $file | git am -3 $sob "$@"
if [ -n "$message_id" ]; then
- commit_add_tag "Link"
"http://patchwork.freedesktop.org/patch/msgid/$message_id";
+ dim_commit_add_tag "Link:
http://patchwork.freedesktop.org/patch/msgid/$message_id";
else
echo "No message-id found in the patch file."
fi
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Move CSB MMIO reads out of the execlists lock
From: Tvrtko Ursulin
By reading the CSB (slow MMIO accesses) into a temporary local
buffer we can decrease the duration of holding the execlist
lock.
Main advantage is that during heavy batch buffer submission we
reduce the execlist lock contention, which should decrease the
latency and CPU usage between the submitting userspace process
and interrupt handling.
Downside is that we need to grab and relase the forcewake twice,
but as the below numbers will show this is completely hidden
by the primary gains.
Testing with "gem_latency -n 100" (submit batch buffers with a
hundred nops each) shows more than doubling of the throughput
and more than halving of the dispatch latency, overall latency
and CPU time spend in the submitting process.
Submitting empty batches ("gem_latency -n 0") does not seem
significantly affected by this change with throughput and CPU
time improving by half a percent, and overall latency worsening
by the same amount.
Above tests were done in a hundred runs on a big core Broadwell.
v2:
* Overflow protection to local CSB buffer.
* Use closer dev_priv in execlists_submit_requests. (Chris Wilson)
v3: Rebase.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c | 77
1 file changed, 38 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f72782200226..c6b3a9d19af2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -416,15 +416,23 @@ static void execlists_update_context(struct
drm_i915_gem_request *rq)
static void execlists_submit_requests(struct drm_i915_gem_request *rq0,
struct drm_i915_gem_request *rq1)
{
+ struct drm_i915_private *dev_priv = rq0->i915;
+
execlists_update_context(rq0);
if (rq1)
execlists_update_context(rq1);
+ spin_lock(&dev_priv->uncore.lock);
+ intel_uncore_forcewake_get__locked(dev_priv, FORCEWAKE_ALL);
+
execlists_elsp_write(rq0, rq1);
+
+ intel_uncore_forcewake_put__locked(dev_priv, FORCEWAKE_ALL);
+ spin_unlock(&dev_priv->uncore.lock);
}
-static void execlists_context_unqueue__locked(struct intel_engine_cs *engine)
+static void execlists_context_unqueue(struct intel_engine_cs *engine)
{
struct drm_i915_gem_request *req0 = NULL, *req1 = NULL;
struct drm_i915_gem_request *cursor, *tmp;
@@ -478,19 +486,6 @@ static void execlists_context_unqueue__locked(struct
intel_engine_cs *engine)
execlists_submit_requests(req0, req1);
}
-static void execlists_context_unqueue(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->dev->dev_private;
-
- spin_lock(&dev_priv->uncore.lock);
- intel_uncore_forcewake_get__locked(dev_priv, FORCEWAKE_ALL);
-
- execlists_context_unqueue__locked(engine);
-
- intel_uncore_forcewake_put__locked(dev_priv, FORCEWAKE_ALL);
- spin_unlock(&dev_priv->uncore.lock);
-}
-
static unsigned int
execlists_check_remove_request(struct intel_engine_cs *engine, u32 request_id)
{
@@ -551,12 +546,10 @@ void intel_lrc_irq_handler(struct intel_engine_cs *engine)
struct drm_i915_private *dev_priv = engine->dev->dev_private;
u32 status_pointer;
unsigned int read_pointer, write_pointer;
- u32 status = 0;
- u32 status_id;
+ u32 csb[GEN8_CSB_ENTRIES][2];
+ unsigned int csb_read = 0, i;
unsigned int submit_contexts = 0;
- spin_lock(&engine->execlist_lock);
-
spin_lock(&dev_priv->uncore.lock);
intel_uncore_forcewake_get__locked(dev_priv, FORCEWAKE_ALL);
@@ -568,41 +561,47 @@ void intel_lrc_irq_handler(struct intel_engine_cs *engine)
write_pointer += GEN8_CSB_ENTRIES;
while (read_pointer < write_pointer) {
- status = get_context_status(engine, ++read_pointer,
- &status_id);
+ if (WARN_ON_ONCE(csb_read == GEN8_CSB_ENTRIES))
+ break;
+ csb[csb_read][0] = get_context_status(engine, ++read_pointer,
+ &csb[csb_read][1]);
+ csb_read++;
+ }
- if (unlikely(status & GEN8_CTX_STATUS_PREEMPTED)) {
- if (status & GEN8_CTX_STATUS_LITE_RESTORE) {
- if (execlists_check_remove_request(engine,
status_id))
+ engine->next_context_status_buffer = write_pointer % GEN8_CSB_ENTRIES;
+
+ /* Update the read pointer to the old write pointer. Manual ringbuffer
+* management ftw */
+ I915_WRITE_FW(RING_CONTEXT_STATUS_PTR(engine),
+ _MASKED_FIELD(GEN8_CSB_READ_PTR_MASK,
+ engine->next_context_status_buffer << 8));
+
+ intel_uncore_forcewake_put__locked(dev_priv, FORCEWAKE_A
Re: [Intel-gfx] [PATCH v2 (rebased) 1/4] drm/i915: Use a crtc mask instead of a refcount for dpll functions, v2.
On Mon, 2016-03-14 at 09:27 +0100, Maarten Lankhorst wrote:
> This makes it easier to verify correct dpll setup with only a single crtc.
> It is also useful to detect double dpll enable/disable.
>
> Changes since v1:
> - Rebase on top of Ander's dpll rework.
> - Change debugfs active to a mask.
> - Change enabled_crtcs and active_crtcs to unsigned.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> drivers/gpu/drm/i915/intel_display.c | 43 +-
> -
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 35 +++-
> drivers/gpu/drm/i915/intel_dpll_mgr.h | 2 +-
> 4 files changed, 43 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d67ab7130c0f..f8fd30bd75bf 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3208,8 +3208,8 @@ static int i915_shared_dplls_info(struct seq_file *m,
> void *unused)
> struct intel_shared_dpll *pll = &dev_priv->shared_dplls[i];
>
> seq_printf(m, "DPLL%i: %s, id: %i\n", i, pll->name, pll->id);
> - seq_printf(m, " crtc_mask: 0x%08x, active: %d, on: %s\n",
> -pll->config.crtc_mask, pll->active, yesno(pll
> ->on));
> + seq_printf(m, " crtc_mask: 0x%08x, active: 0x%x, on: %s\n",
> +pll->config.crtc_mask, pll->active_mask, yesno(pll
> ->on));
> seq_printf(m, " tracked hardware state:\n");
> seq_printf(m, " dpll:0x%08x\n", pll
> ->config.hw_state.dpll);
> seq_printf(m, " dpll_md: 0x%08x\n",
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5a95dcf68df1..f8f02ec201b7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12973,7 +12973,7 @@ check_shared_dpll_state(struct drm_device *dev)
> for (i = 0; i < dev_priv->num_shared_dpll; i++) {
> struct intel_shared_dpll *pll =
> intel_get_shared_dpll_by_id(dev_priv, i);
> - int enabled_crtcs = 0, active_crtcs = 0;
> + unsigned enabled_crtcs = 0, active_crtcs = 0;
> bool active;
>
> memset(&dpll_hw_state, 0, sizeof(dpll_hw_state));
> @@ -12982,15 +12982,15 @@ check_shared_dpll_state(struct drm_device *dev)
>
> active = pll->funcs.get_hw_state(dev_priv, pll,
> &dpll_hw_state);
>
> - I915_STATE_WARN(pll->active > hweight32(pll
> ->config.crtc_mask),
> - "more active pll users than references: %i vs %i\n",
> - pll->active, hweight32(pll->config.crtc_mask));
> - I915_STATE_WARN(pll->active && !pll->on,
> - "pll in active use but not on in sw tracking\n");
> + I915_STATE_WARN(pll->active_mask & ~pll->config.crtc_mask,
> + "more active pll users than references: %x vs %x\n",
> + pll->active_mask, pll->config.crtc_mask);
>
> if (!(pll->flags & INTEL_DPLL_ALWAYS_ON)) {
> - I915_STATE_WARN(pll->on && !pll->active,
> - "pll in on but not on in use in sw tracking\n");
> + I915_STATE_WARN(!pll->on && pll->active_mask,
> + "pll in active use but not on in sw
> tracking\n");
> + I915_STATE_WARN(pll->on && !pll->active_mask,
> + "pll is on but not used by any active crtc\n");
> I915_STATE_WARN(pll->on != active,
>"pll on state mismatch (expected %i, found
> %i)\n",
>pll->on, active);
> @@ -12998,16 +12998,17 @@ check_shared_dpll_state(struct drm_device *dev)
>
> for_each_intel_crtc(dev, crtc) {
> if (crtc->base.state->enable && crtc->config
> ->shared_dpll == pll)
> - enabled_crtcs++;
> - if (crtc->active && crtc->config->shared_dpll == pll)
> - active_crtcs++;
> + enabled_crtcs |= 1 << drm_crtc_index(&crtc
> ->base);
> + if (crtc->base.state->active && crtc->config
> ->shared_dpll == pll)
> + active_crtcs |= 1 << drm_crtc_index(&crtc
> ->base);
> }
> - I915_STATE_WARN(pll->active != active_crtcs,
> - "pll active crtcs mismatch (expected %i, found %i)\n",
> - pll->active, active_crtcs);
> - I915_STATE_WARN(hweight32(pll->config.crtc_mask) !=
> enabled_crtcs,
> - "pll enabled crtcs mismatch (expected %i, found %i)\n",
> - hweight32(pll->config.crtc_mask), enabled_crtcs);
> +
> + I915_STATE_WARN(pl
Re: [Intel-gfx] [PATCH v3 19/19] drm/i915: Add fault injection support
On Wed, 2016-03-16 at 12:44 +, Chris Wilson wrote: > On Wed, Mar 16, 2016 at 02:12:35PM +0200, Imre Deak wrote: > > On Wed, 2016-03-16 at 12:00 +, Chris Wilson wrote: > > > On Wed, Mar 16, 2016 at 01:39:08PM +0200, Imre Deak wrote: > > > > Add support for forcing an error at selected places in the > > > > driver. > > > > As an > > > > example add 4 options to fail during driver loading. > > > > > > > > Requested by Chris. > > > > > > > > v2: > > > > - Add fault point for modeset initialization > > > > - Print debug message when injecting an error > > > > v3: > > > > - Rename inject_fault to inject_load_failure, rename the > > > > related > > > > macros > > > > and helper accordingly (Chris) > > > > - Use a counter instead of a mask to identify the failure point > > > > (Daniel) > > > > - Mark the module option as _unsafe and keep i915_params > > > > ordered > > > > (Joonas) > > > > > > Now that you have something so simple to use, putting a failure > > > point > > > at > > > the start and end of each init_func is trivial (to test the local > > > unwind > > > in each function as well as the global unwind). > > > > Ok can do this, but again preferably as a follow-up: > > i915_load_modeset_init() has pre-existing issues, the last thing I > > checked was some running work item that gets scheduled after we > > removed > > the module already (maybe the eDP VDD work). I'll track down that > > and > > try to clean up the rest of problems I see in > > i915_load_modeset_init(); > > with those I could add the additional checkpoints you suggest. > > Should we expose the injection fault count so that we can automate > repeating the module reload for the right number of cycles? Yes, can add that. --Imre > -Chris > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 06/19] drm/i915: Move load time runtime device info init earlier
This init step accesses the device, but doesn't have any device
specific side effect. It also sets up some platform specific
attributes that may be required early, so move it earlier.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_dma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 60e8fe6..da96ccd 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1057,6 +1057,8 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
intel_uncore_init(dev);
+ intel_device_info_runtime_init(dev);
+
ret = i915_gem_gtt_init(dev);
if (ret)
goto out_uncore_fini;
@@ -1131,8 +1133,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
DRM_DEBUG_DRIVER("can't enable MSI");
}
- intel_device_info_runtime_init(dev);
-
if (INTEL_INFO(dev)->num_pipes) {
ret = drm_vblank_init(dev, INTEL_INFO(dev)->num_pipes);
if (ret)
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/gtt: Reference mappable_end variable from pointer
On 18/03/16 08:42, Joonas Lahtinen wrote:
Reference variable value from pointer, not assumed pointer destination.
Since:
commit c44ef60e437019b8ca1dab8b4d2e8761fd4ce1e9
Author: Mika Kuoppala
Date: Thu Jun 25 18:35:05 2015 +0300
drm/i915/gtt: Allow >= 4GB sizes for vm.
Cc: Mika Kuoppala
Reviewed-by: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9c752fe..5c90952 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3103,8 +3103,7 @@ static int gen6_gmch_probe(struct drm_device *dev,
* a coarse sanity check.
*/
if ((*mappable_end < (64<<20) || (*mappable_end > (512<<20 {
- DRM_ERROR("Unknown GMADR size (%llx)\n",
- dev_priv->gtt.mappable_end);
+ DRM_ERROR("Unknown GMADR size (%llx)\n", *mappable_end);
return -ENXIO;
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] mm/vmap: Add a notifier for when we run out of vmap address space
On Thu, Mar 17, 2016 at 01:34:59PM +, Chris Wilson wrote: > vmaps are temporary kernel mappings that may be of long duration. > Reusing a vmap on an object is preferrable for a driver as the cost of > setting up the vmap can otherwise dominate the operation on the object. > However, the vmap address space is rather limited on 32bit systems and > so we add a notification for vmap pressure in order for the driver to > release any cached vmappings. > > The interface is styled after the oom-notifier where the callees are > passed a pointer to an unsigned long counter for them to indicate if they > have freed any space. > > v2: Guard the blocking notifier call with gfpflags_allow_blocking() > > Signed-off-by: Chris Wilson > Cc: Andrew Morton > Cc: David Rientjes > Cc: Roman Peniaev > Cc: Mel Gorman > Cc: linux...@kvack.org > Cc: linux-ker...@vger.kernel.org > --- > include/linux/vmalloc.h | 4 > mm/vmalloc.c| 27 +++ > 2 files changed, 31 insertions(+) > > diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > index d1f1d338af20..edd676b8e112 100644 > --- a/include/linux/vmalloc.h > +++ b/include/linux/vmalloc.h > @@ -187,4 +187,8 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms) > #define VMALLOC_TOTAL 0UL > #endif > > +struct notitifer_block; Omg. /o\ -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
