Re: [Intel-gfx] [PATCH v5 30/46] regulator: pwm: retrieve correct voltage

[Mark Brown]

On Thu, Apr 07, 2016 at 11:54:31PM +0200, Boris Brezillon wrote:

> Is there any reason for calling set_machine_constraints() after
> device_register() in regulator_register()?

I'm not sure there's a strong one, we don't really use the class device
for anything, but without doing a full audit I couldn't guarantee that.


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

Re: [Intel-gfx] i951 ERRORs and WARN_ON()s (was: blank screen on boot with i915/DRM_FBDEV_EMULATION)

[Florian Zumbiehl]

Hi,

> > We've fixed piles of those in recent kernels, but didn't backport all the
> > fixes (since usually it's a silent failure, but it can correlate with
> > black screens).
> 
> Not quite completely, it seems ...
> 
> I have built drm-intel-nightly (f261f82359), and I'm getting this:
[...]

ping?

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

Re: [Intel-gfx] [PATCH v5 00/46] pwm: add support for atomic update

[Boris Brezillon]

Hi Thierry,

On Wed, 30 Mar 2016 22:03:23 +0200
Boris Brezillon  wrote:

> Hello,
> 
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.
> 
> It also adds support for initial PWM state retrieval (or hardware readout),
> which should allow smooth handover between the bootloader and Linux. For
> example, critical PWM users (like critical regulators controlled by a PWM)
> can query the current PWM state, and adapt the PWM config without having
> to disable/enable the PWM, or abruptly change the period/dutycyle/polarity
> config.
> 
> Thierry, I hope this version meets your expectations, if that's not the
> case, could you let me know quickly so I can adjust the implementation
> accordingly (I'd really like to get most of those changes in 4.7).

Still haven't had a clear feedback from your side on this series (you
commented on a few details, but nothing on the general approach). Could
you please have at a quick look at it, and let me know if I should
adjust the implementation?

Note that I plan to send a new version  addressing comments made by
other maintainers/developers by the end of the week. In the meantime,
could you have a look at the first set of patches (patch 1 to 4 are
completely independent), and apply them if you're happy with it.

As you can see, I now have a lot of patches. This helps in showing the
big picture, but also annoys people when I send this 50+ patchset. So,
if you don't mind, I'd like to drop the changes touching PWM user
drivers (to make them use the atomic API) until we get the other parts
applied.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

[Lyude Paul]

NAK. Try plugging in an MST display, suspending the machine, then resuming it.
Hotplugging still breaks (which I've traced down to this patch)

I wouldn't worry about fixing this up. I'm probably going to be sending a revert
for this anyway soon along with probably some of the other patches.

On Mon, 2016-04-11 at 10:11 -0700, Jim Bride wrote:
> In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some
> much needed clean-up was done, but unfortunately part of the change
> broke DP MST.  The real issue was setting the connector state to
> disconnected in the MST case, which is good, but the code then (after
> a goto) checks if the connector state is not connected and shuts down
> MST if this is the case, which is bad.  With this change both SST and
> MST seem to be happy.
> 
> v2: Add removed check further up in the function to be sure that MST
> is shut down when we lose the link. (Ander)
> 
> Fixes: commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
> cc: Sivakumar Thulasimani 
> cc: Shubhangi Shrivastava 
> cc: Ander Conselvan de Oliveira 
> cc: Nathan D Ciobanu 
> Signed-off-by: Jim Bride 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 24 +++-
>  1 file changed, 11 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index da0c3d2..31b222a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4608,6 +4608,15 @@ intel_dp_long_pulse(struct intel_connector
> *intel_connector)
>   intel_dp->compliance_test_type = 0;
>   intel_dp->compliance_test_data = 0;
>  
> + if (intel_dp->is_mst) {
> + DRM_DEBUG_KMS("MST device may have disappeared %d vs
> %d\n",
> +   intel_dp->is_mst,
> +   intel_dp->mst_mgr.mst_state);
> + intel_dp->is_mst = false;
> + drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> + intel_dp->is_mst);
> + }
> +
>   goto out;
>   }
>  
> @@ -4665,20 +4674,9 @@ intel_dp_long_pulse(struct intel_connector
> *intel_connector)
>   }
>  
>  out:
> - if (status != connector_status_connected) {
> + if ((status != connector_status_connected) &&
> + (intel_dp->is_mst == false))
>   intel_dp_unset_edid(intel_dp);
> - /*
> -  * If we were in MST mode, and device is not there,
> -  * get out of MST mode
> -  */
> - if (intel_dp->is_mst) {
> - DRM_DEBUG_KMS("MST device may have disappeared %d vs
> %d\n",
> -   intel_dp->is_mst, intel_dp-
> >mst_mgr.mst_state);
> - intel_dp->is_mst = false;
> - drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
> - intel_dp->is_mst);
> - }
> - }
>  
>   intel_display_power_put(to_i915(dev), power_domain);
>   return;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] Fixing up relocation of secure buffers?

[Chris Wilson]

On Mon, Apr 11, 2016 at 07:47:12PM +0100, Dave Gordon wrote:
> Hi,
> 
> background to this is that one of our validation engineers has written
> a test that creates a batch that loops by jumping backwards using
> MI_BATCH_BUFFER_START to an address earlier in the batchbuffer, with
> whatever instruction sequence is being tested inside the loop.
> 
> This works perfectly well for normal cases, but in some cases the
> instruction to be tested is privileged, so the batch has to be submitted
> with the I915_DISPATCH_SECURE flag.
> 
> In this case, although the batch executes correctly on the first pass,
> the jump backwards doesn't. It appears that the relocation process has
> inserted a PPGTT-based address for the target, whereas the opcode in
> the batch has the GGTT bit set (as required for jumping to a privileged
> batch). The result is effectively a random jump :(

Tricky. Problem here is that even some relocations will read from the
ppgtt but a few will read from the ggtt. I was going to suggest a second
relocation pass for the ggtt secure batch - but we can't tell which will
be which. We do have the NEEDS_GGTT execobject flag, but that is not
allowed on full-ppgtt (atm). We could look for a read_domain = COMMAND,
but that will likely end up in confusion - though at first glance that
seems good enough.

So a second relocation pass for the secure batch applying the GGTT
offset to self-relocations with read_domain == COMMAND? (Being sure not
to apply the pass to promoted cmdparser batches.) The
relocation[].presumed_offsets should be set to -1, as should the
execobject.offset since the relocations are then inconsistent.
-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] Updated drm-intel-testing

[Felix Miata]

Daniel Vetter composed on 2016-04-11 21:45 (UTC+0200):


New -testing cycle with cool stuff:...


What exactly is a "testing cycle? Last Intel Xorg driver (e.g. openSUSE 42.1 
released in November: xf86-video-intel; Ubuntu 16.04, due out this month: 
xserver-xorg-video-intel) release was, what, 19 months ago, a perpetual beta 
(2.99.99?)?


Is the meaning of "cycle" (as opposed to actual dates involved for any 
particular cycle) any different for drm, Mesa or other components than for 
the xorg "driver"?

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Updated drm-intel-testing

[Daniel Vetter]

Hi all,

New -testing cycle with cool stuff:
- make modeset hw state checker atomic aware (Maarten)
- close races in gpu stuck detection/seqno reading (Chris)
- tons of small improvements from Chris Wilson all over the gem code
- more dsi/bxt work from Ramalingam
- macro polish from Joonas
- guc fw loading fixes (Arun)
- vmap notifier (acked by Andrew) + i915 support by Chris Wilson
- create bottom half for execlist irq processing (Chris Wilson)
- vlv/chv pll cleanup (Ville)
- rework DP detection, especially sink detection (Shubhangi Shrivastava)
- make color manager support fully atomic (Maarten)
- avoid livelock on chv in execlist irq handler (Chris)

Happy testing!

Cheers, Daniel

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

[Intel-gfx] [RFC] Fixing up relocation of secure buffers?

[Dave Gordon]

Hi,

background to this is that one of our validation engineers has written
a test that creates a batch that loops by jumping backwards using
MI_BATCH_BUFFER_START to an address earlier in the batchbuffer, with
whatever instruction sequence is being tested inside the loop.

This works perfectly well for normal cases, but in some cases the
instruction to be tested is privileged, so the batch has to be submitted
with the I915_DISPATCH_SECURE flag.

In this case, although the batch executes correctly on the first pass,
the jump backwards doesn't. It appears that the relocation process has
inserted a PPGTT-based address for the target, whereas the opcode in
the batch has the GGTT bit set (as required for jumping to a privileged
batch). The result is effectively a random jump :(

So, I put this little patch together, in which we pass TWO address spaces
to eb_lookup_vmas(), one to be used for the batch (object 0 in the args)
and the other for all other buffer objects. Then we can either pass
the same address space for both (regular non-privileged batch, or h/w
doesn't support PPGTT), or GGTT for the batch and PPGTT for the rest.

That part appears to work, but the relocation is still wrong i.e. using
a PPGTT-based address rather than the VMA associated with object 0. So,
any pointers as to why relocation isn't using the right VM?

Oh yes, also the code in i915_gem_execbuffer_relocate_slow() is a hack.
What would be the right way to recover vm0 and vm in this function? But 
we're not reaching that code yet, AFAIK.

Thanks,
.Dave.

Cc: Miguel Reche 

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

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0ee61fd..84f590c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -93,6 +93,7 @@ struct eb_vmas {
 eb_lookup_vmas(struct eb_vmas *eb,
   struct drm_i915_gem_exec_object2 *exec,
   const struct drm_i915_gem_execbuffer2 *args,
+  struct i915_address_space *vm0,
   struct i915_address_space *vm,
   struct drm_file *file)
 {
@@ -143,7 +144,7 @@ struct eb_vmas {
 * from the (obj, vm) we don't run the risk of creating
 * duplicated vmas for the same vm.
 */
-   vma = i915_gem_obj_lookup_or_create_vma(obj, vm);
+   vma = i915_gem_obj_lookup_or_create_vma(obj, i ? vm : vm0);
if (IS_ERR(vma)) {
DRM_DEBUG("Failed to lookup VMA\n");
ret = PTR_ERR(vma);
@@ -831,14 +832,15 @@ static bool only_mappable_for_reloc(unsigned int flags)
  struct intel_context *ctx)
 {
struct drm_i915_gem_relocation_entry *reloc;
-   struct i915_address_space *vm;
+   struct i915_address_space *vm0, *vm;
struct i915_vma *vma;
bool need_relocs;
int *reloc_offset;
int i, total, ret;
unsigned count = args->buffer_count;
 
-   vm = list_first_entry(>vmas, struct i915_vma, exec_list)->vm;
+   vm0 = list_first_entry(>vmas, struct i915_vma, exec_list)->vm;
+   vm = list_last_entry(>vmas, struct i915_vma, exec_list)->vm;
 
/* We may process another execbuffer during the unlock... */
while (!list_empty(>vmas)) {
@@ -909,7 +911,7 @@ static bool only_mappable_for_reloc(unsigned int flags)
 
/* reacquire the objects */
eb_reset(eb);
-   ret = eb_lookup_vmas(eb, exec, args, vm, file);
+   ret = eb_lookup_vmas(eb, exec, args, vm0, vm, file);
if (ret)
goto err;
 
@@ -1440,7 +1442,7 @@ static bool only_mappable_for_reloc(unsigned int flags)
struct drm_i915_gem_exec_object2 shadow_exec_entry;
struct intel_engine_cs *engine;
struct intel_context *ctx;
-   struct i915_address_space *vm;
+   struct i915_address_space *vm0, *vm;
struct i915_execbuffer_params params_master; /* XXX: will be removed 
later */
struct i915_execbuffer_params *params = _master;
const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
@@ -1508,6 +1510,12 @@ static bool only_mappable_for_reloc(unsigned int flags)
else
vm = >base;
 
+   /* Secure batches must live in GGTT */
+   if (dispatch_flags & I915_DISPATCH_SECURE)
+   vm0 = _priv->ggtt.base;
+   else
+   vm0 = vm;
+
memset(_master, 0x00, sizeof(params_master));
 
eb = eb_create(args);
@@ -1519,7 +1527,7 @@ static bool only_mappable_for_reloc(unsigned int flags)
}
 
/* Look up object handles */
-   ret = eb_lookup_vmas(eb, exec, args, vm, file);
+   ret = eb_lookup_vmas(eb, exec, args, vm0, vm, file);
if (ret)
goto err;
 
-- 
1.9.1

[Intel-gfx] [PATCH i-g-t] ksm_pipe_color: Set legacy gamma values inside loop.

[Bob Paauwe]

When testing multple outputs, make sure to set the gamma values before
testing the output.  Otherwise we're testing using the gamma values
that were reset after last output was tested.  Without this, the first
output passes, but each output after that will fail.

Signed-off-by: Bob Paauwe 
---
 tests/kms_pipe_color.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/kms_pipe_color.c b/tests/kms_pipe_color.c
index f08aabd..9f7ac7e 100644
--- a/tests/kms_pipe_color.c
+++ b/tests/kms_pipe_color.c
@@ -452,10 +452,6 @@ static void test_pipe_legacy_gamma(data_t *data,
green_lut = malloc(sizeof(uint16_t) * legacy_lut_size);
blue_lut = malloc(sizeof(uint16_t) * legacy_lut_size);
 
-   red_lut[0] = green_lut[0] = blue_lut[0] = 0;
-   for (i = 1; i < legacy_lut_size; i++)
-   red_lut[i] = green_lut[i] = blue_lut[i] = 0x;
-
for_each_connected_output(>display, output) {
drmModeModeInfo *mode;
struct igt_fb fb_modeset, fb;
@@ -500,6 +496,10 @@ static void test_pipe_legacy_gamma(data_t *data,
 */
paint_gradient_rectangles(data, mode, red_green_blue, );
igt_plane_set_fb(primary, );
+
+   red_lut[0] = green_lut[0] = blue_lut[0] = 0;
+   for (i = 1; i < legacy_lut_size; i++)
+   red_lut[i] = green_lut[i] = blue_lut[i] = 0x;
igt_assert_eq(drmModeCrtcSetGamma(data->drm_fd, 
primary->pipe->crtc_id,
  legacy_lut_size, red_lut, 
green_lut, blue_lut), 0);
igt_display_commit(>display);
-- 
2.5.5

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

Re: [Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

[Bob Paauwe]

On Mon, 11 Apr 2016 14:43:39 +0100
Lionel Landwerlin  wrote:

> Color management properties are a bit of an odd use case because
> they're not marked as atomic properties. Currently we're not updating
> the non atomic values so the drm_crtc_state is out of sync with the
> values stored in the crtc object.
> 
> v2: Update non atomic values only if commit succeeds (Bob Paauwe)
> 
> v3: Do not access crtc_state after commit, use crtc->state (Maarten
> Lankhorst)
> 

Reviewed-by: Bob Paauwe 
Tested-by; Bob Paauwe 

> Cc: Maarten Lankhorst 
> Cc: Bob Paauwe 
> Cc: 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 7bf678e..13b86cf 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2979,6 +2979,14 @@ retry:
>   if (ret)
>   goto fail;
>  
> + drm_object_property_set_value(>base,
> + config->degamma_lut_property, 0);
> + drm_object_property_set_value(>base,
> + config->ctm_property, 0);
> + drm_object_property_set_value(>base,
> + config->gamma_lut_property,
> + crtc->state->gamma_lut->base.id);
> +
>   /* Driver takes ownership of state on successful commit. */
>  
>   drm_property_unreference_blob(blob);



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

[Intel-gfx] [PATCH v2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

[Jim Bride]

In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some
much needed clean-up was done, but unfortunately part of the change
broke DP MST.  The real issue was setting the connector state to
disconnected in the MST case, which is good, but the code then (after
a goto) checks if the connector state is not connected and shuts down
MST if this is the case, which is bad.  With this change both SST and
MST seem to be happy.

v2: Add removed check further up in the function to be sure that MST
is shut down when we lose the link. (Ander)

Fixes: commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
cc: Sivakumar Thulasimani 
cc: Shubhangi Shrivastava 
cc: Ander Conselvan de Oliveira 
cc: Nathan D Ciobanu 
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/intel_dp.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index da0c3d2..31b222a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4608,6 +4608,15 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_dp->compliance_test_type = 0;
intel_dp->compliance_test_data = 0;
 
+   if (intel_dp->is_mst) {
+   DRM_DEBUG_KMS("MST device may have disappeared %d vs 
%d\n",
+ intel_dp->is_mst,
+ intel_dp->mst_mgr.mst_state);
+   intel_dp->is_mst = false;
+   drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
+   intel_dp->is_mst);
+   }
+
goto out;
}
 
@@ -4665,20 +4674,9 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
}
 
 out:
-   if (status != connector_status_connected) {
+   if ((status != connector_status_connected) &&
+   (intel_dp->is_mst == false))
intel_dp_unset_edid(intel_dp);
-   /*
-* If we were in MST mode, and device is not there,
-* get out of MST mode
-*/
-   if (intel_dp->is_mst) {
-   DRM_DEBUG_KMS("MST device may have disappeared %d vs 
%d\n",
- intel_dp->is_mst, 
intel_dp->mst_mgr.mst_state);
-   intel_dp->is_mst = false;
-   drm_dp_mst_topology_mgr_set_mst(_dp->mst_mgr,
-   intel_dp->is_mst);
-   }
-   }
 
intel_display_power_put(to_i915(dev), power_domain);
return;
-- 
2.5.0

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

[Intel-gfx] [PATCH v4] test/gem_mocs_settings: Testing MOCS register settings

[Peter Antoine]

The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second set controls
the L3 policy. The two sets use the same index.

The RCS registers and the L3CC registers are stored in the RCS context.

The test checks that the registers are correct by checking the values by
directly reading them via MMIO, then again it tests them by reading them
from within a batch buffer. RCS engine is tested last as it programs the
registers via a batch buffer and this will invalidate the test for
workloads that don't use the render ring or don't run a render batch
first.

v2: Reorganised the structure.
Added more tests. (Chris Wilson)
v3: Fixed a few bugs. (Chris Wilson)
v4: More Tidy-ups.(Chris Wilson)
SKL does does not have a snoop bit. (Peter Antoine)

Signed-off-by: Peter Antoine 
---
 lib/ioctl_wrappers.c  |  13 ++
 lib/ioctl_wrappers.h  |   1 +
 tests/Makefile.sources|   1 +
 tests/gem_mocs_settings.c | 573 ++
 4 files changed, 588 insertions(+)
 create mode 100644 tests/gem_mocs_settings.c

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 076bce8..12912fe 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1382,6 +1382,19 @@ void gem_require_ring(int fd, unsigned ring)
igt_require(gem_has_ring(fd, ring));
 }
 
+/**
+ * gem_require_mocs:
+ * @fd: open i915 drm file descriptor
+ *
+ * Feature test macro to query whether the device has MOCS registers.
+ * These exist gen 9+.
+ */
+void gem_require_mocs(int fd)
+{
+   const int gen = intel_gen(intel_get_drm_devid(fd));
+   igt_require(gen >= 9);
+}
+
 /* prime */
 
 /**
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index d986f61..1383062 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -154,6 +154,7 @@ bool gem_has_softpin(int fd);
 void gem_require_caching(int fd);
 bool gem_has_ring(int fd, unsigned ring);
 void gem_require_ring(int fd, unsigned ring);
+void gem_require_mocs(int fd);
 
 /* prime */
 struct local_dma_buf_sync {
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 43f232f..d483c9e 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -148,6 +148,7 @@ TESTS_progs = \
gem_lut_handle \
gem_mmap_offset_exhaustion \
gem_media_fill \
+   gem_mocs_settings \
gem_gpgpu_fill \
gem_pin \
gem_reg_read \
diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
new file mode 100644
index 000..c11b9c5
--- /dev/null
+++ b/tests/gem_mocs_settings.c
@@ -0,0 +1,573 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+/** @file gem_mocs_settings.c
+ *
+ * Check that the MOCs cache settings are valid.
+ */
+
+#include "igt.h"
+#include "igt_gt.h"
+
+#define MAX_NUMBER_MOCS_REGISTERS  (64)
+
+enum {
+   NONE,
+   RESET,
+   SUSPEND,
+   HIBERNATE
+};
+
+#define GEN9_LNCFCMOCS0(0xB020)/* L3 Cache Control 
base */
+#define GEN9_GFX_MOCS_0(0xc800)/* Graphics MOCS base 
register*/
+#define GEN9_MFX0_MOCS_0   (0xc900)/* Media 0 MOCS base register*/
+#define GEN9_MFX1_MOCS_0   (0xcA00)/* Media 1 MOCS base register*/
+#define GEN9_VEBOX_MOCS_0  (0xcB00)/* Video MOCS base register*/
+#define GEN9_BLT_MOCS_0(0xcc00)/* Blitter MOCS base 
register*/
+
+#define ENGINE_GFX (I915_EXEC_RENDER)
+#define ENGINE_MFX0(I915_EXEC_BSD)
+#define ENGINE_MFX0_ALT(I915_EXEC_BSD | 1 << 13)
+#define ENGINE_MFX1(I915_EXEC_BSD | 2 << 13)
+#define ENGINE_BLT (I915_EXEC_BLT)
+#define ENGINE_VEBOX   (I915_EXEC_VEBOX)
+
+struct mocs_entry {
+   uint32_t

[Intel-gfx] ✗ Fi.CI.BAT: failure for Minor i915_dp_mst_info output enhancements (rev4)

[Patchwork]

== Series Details ==

Series: Minor i915_dp_mst_info output enhancements (rev4)
URL   : https://patchwork.freedesktop.org/series/5346/
State : failure

== Summary ==

  CC  net/ipv4/tcp_cubic.o
  CC  net/ipv4/xfrm4_policy.o
  CC  net/ipv6/xfrm6_input.o
  CC  net/ipv4/xfrm4_state.o
  CC  net/ipv4/xfrm4_input.o
  CC  net/ipv4/xfrm4_output.o
  CC  net/ipv6/xfrm6_output.o
  CC  net/ipv4/xfrm4_protocol.o
  CC  net/ipv6/xfrm6_protocol.o
  CC  net/ipv6/fib6_rules.o
  CC  net/ipv6/proc.o
  CC  net/ipv6/syncookies.o
  CC  net/ipv6/mip6.o
  CC  net/ipv6/addrconf_core.o
  CC  net/ipv6/exthdrs_core.o
  CC  net/ipv6/ip6_checksum.o
  CC  net/ipv6/ip6_icmp.o
  CC  net/ipv6/output_core.o
  CC  net/ipv6/protocol.o
  CC  net/ipv6/ip6_offload.o
  CC  net/ipv6/tcpv6_offload.o
  CC  net/ipv6/udp_offload.o
  CC  net/ipv6/exthdrs_offload.o
  LD  net/xfrm/built-in.o
  CC  net/ipv6/inet6_hashtables.o
  CC  net/ipv6/mcast_snoop.o
  LD  net/ipv4/built-in.o
  LD  net/ipv6/ipv6.o
  LD  net/ipv6/built-in.o
  LD  net/built-in.o

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

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

[Chris Wilson]

On Mon, Apr 11, 2016 at 03:57:21PM +0100, Tvrtko Ursulin wrote:
> 
> On 11/04/16 15:44, Chris Wilson wrote:
> >On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 08/04/16 12:11, Chris Wilson wrote:
> >>>When called because we have run out of vmap address space, we only need
> >>>to recover objects that have vmappings and not all.
> >>>
> >>>v2: Start using is_vmalloc_addr()
> >>>
> >>>Signed-off-by: Chris Wilson 
> >>>Cc: Tvrtko Ursulin 
> >>>---
> >>>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >>>  drivers/gpu/drm/i915/i915_gem_shrinker.c | 10 +-
> >>>  2 files changed, 10 insertions(+), 1 deletion(-)
> >>
> >>Reviewed-by: Tvrtko Ursulin 
> >
> >Having started to use the obj->mapping cache in anger, do you think there
> >is any left before pushing this part of the puzzle? I'm hitting an
> >interesting scaling problem with vmalloc's lazy free list (that's a
> >patch for later!).
> 
> Looks ready and useful to me so I vote for merging it.

Done. Hopefully I can make some headway on bugfixes and then start
chasing some of the more interesting improvements.
-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 07/10] drm/i915: Warn if irq_mask isn't ~0 during vlv/cvh display irq postinstall

[Imre Deak]

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> We expect vlv_display_irq_reset() to have been called prior to
> vlv_display_irq_postinstall() so let's WARN if that isn't the case.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index f6815e47d8de..872f93dc68ff 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3318,6 +3318,9 @@ static void vlv_display_irq_postinstall(struct
> drm_i915_private *dev_priv)
>   I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
>   if (IS_CHERRYVIEW(dev_priv))
>   enable_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
> +
> + WARN_ON(dev_priv->irq_mask != ~0);
> +
>   dev_priv->irq_mask = ~enable_mask;
>  
>   GEN5_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] test/gem_mocs_settings: Testing MOCS register settings

[Peter Antoine]

On Mon, 11 Apr 2016, Chris Wilson wrote:


On Mon, Apr 11, 2016 at 04:02:17PM +0100, Peter Antoine wrote:

+   for (index = 0, offset = 0; index < size; index++, offset += 4)
+   {
+   batch[offset]   = MI_STORE_REGISTER_MEM_64_BIT_ADDR;
+   batch[offset+1] = reg_base + (index * sizeof(uint32_t));
+   batch[offset+2] = index * sizeof(uint32_t); /* reloc */
+   batch[offset+3] = 0;
+
+   reloc[index].offset = (offset + 2) * sizeof(uint32_t);
+   reloc[index].delta = index * sizeof(uint32_t);
+   reloc[index].target_handle = dst_handle;
+   reloc[index].write_domain = I915_GEM_DOMAIN_RENDER;


Will cause an -EINVAL as you are specifing a write_domain but not the
corresponding read_domain.

Removed.


I hope you meant added the missing read_domains!


(Did not cause an error when tested)


Hmm, ok we don't actually warn about that!


BXT no error, SKL error (different versions of the kernel).
Added missing read_domains.


+static void do_read_registers(int fd,
+ uint32_t ctx_id,
+ uint32_t dst_handle,
+ uint32_t reg_base,
+ uint32_t size,
+ uint32_t engine_id)
+{
+   gem_execbuf(fd, );
+   gem_wait(fd, dst_handle, _ns);


As mentioned earlier, tried to avoid manual wait/sync so that we stress
the kernel harder to do the right thing. Sometimes the sync is required
as part of the test, but only rarely and should be well documented.

replaced with set_domain.




+   gem_close(fd, handle);
+}



+static void check_control_registers(int fd,
+   const struct intel_execution_engine *engine,
+   uint32_t ctx_id,
+   bool dirty)
+{
+   uint32_t dst_handle = gem_create(fd, 4096);
+   uint32_t reg_base  = get_engine_base(engine->exec_id | engine->flags);
+   uint32_t *read_regs;
+   struct mocs_table table;
+
+   igt_assert(get_mocs_settings(intel_get_drm_devid(fd), , dirty));
+
+   do_read_registers(fd,
+ ctx_id,
+ dst_handle,
+ reg_base,
+ table.size,
+ engine->exec_id | engine->flags);
+
+   read_regs = gem_mmap__cpu(fd, dst_handle, 0, 4096, PROT_READ);


Here you need the corresponding
gem_set_comdin(fd, dst_handle, DOMAIN_CPU, 0);
and in check_l3cc_registers.

Added into do_read_registers() so should handle both.


But less explicit and doesn't document the code as well. Move the
set-domain next to the usage of dst_handle in the CPU domain.
-Chris



Moved out of do_ream_domain()

Found an issue on SKL, it does not have the snoop bit that the BXT has, 
changed test so that the dirty check takes account of the different 
settable bits.


Version 4, coming now.

Peter.

--
   Peter Antoine (Android Graphics Driver Software Engineer)
   -
   Intel Corporation (UK) Limited
   Registered No. 1134945 (England)
   Registered Office: Pipers Way, Swindon SN3 1RJ
   VAT No: 860 2173 47
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/10] drm/i915: Use GEN5_IRQ_INIT() in vlv_display_irq_postinstall()

[Imre Deak]

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Replace the hand rolled IMR/IER setup in
> vlv_display_irq_postinstall()
> with GEN5_IRQ_INIT(). Also rename the iir_mask to enable_mask to
> avoid
> consusion since we no longer deal with IIR here.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 678c6b86862e..f6815e47d8de 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3303,7 +3303,7 @@ static void vlv_display_irq_reset(struct
> drm_i915_private *dev_priv)
>  static void vlv_display_irq_postinstall(struct drm_i915_private
> *dev_priv)
>  {
>   u32 pipestat_mask;
> - u32 iir_mask;
> + u32 enable_mask;
>   enum pipe pipe;
>  
>   pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
> @@ -3313,18 +3313,14 @@ static void
> vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
>   for_each_pipe(dev_priv, pipe)
>   i915_enable_pipestat(dev_priv, pipe, pipestat_mask);
>  
> - iir_mask = I915_DISPLAY_PORT_INTERRUPT |
> -    I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
> -    I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
> + enable_mask = I915_DISPLAY_PORT_INTERRUPT |
> + I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
> + I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
>   if (IS_CHERRYVIEW(dev_priv))
> - iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
> - dev_priv->irq_mask &= ~iir_mask;
> -
> - I915_WRITE(VLV_IIR, iir_mask);
> - I915_WRITE(VLV_IIR, iir_mask);
> - I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
> - I915_WRITE(VLV_IMR, dev_priv->irq_mask);
> - POSTING_READ(VLV_IMR);
> + enable_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
> + dev_priv->irq_mask = ~enable_mask;
> +
> + GEN5_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
>  }
>  
>  /* drm_dma.h hooks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Clear display interrupt before enabling when turning on the power well

[Imre Deak]

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> For a bit of extra paranoia make sure the display irqs are all
> cleared
> before we enabled them when turning on the power well. This should
> really be the case already since the power well was off which resets
> everything.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index c119610e2d57..678c6b86862e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3306,13 +3306,6 @@ static void vlv_display_irq_postinstall(struct
> drm_i915_private *dev_priv)
>   u32 iir_mask;
>   enum pipe pipe;
>  
> - pipestat_mask = PIPESTAT_INT_STATUS_MASK |
> - PIPE_FIFO_UNDERRUN_STATUS;
> -
> - for_each_pipe(dev_priv, pipe)
> - I915_WRITE(PIPESTAT(pipe), pipestat_mask);
> - POSTING_READ(PIPESTAT(PIPE_A));
> -
>   pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
>   PIPE_CRC_DONE_INTERRUPT_STATUS;
>  
> @@ -3696,8 +3689,10 @@ void valleyview_enable_display_irqs(struct
> drm_i915_private *dev_priv)
>  
>   dev_priv->display_irqs_enabled = true;
>  
> - if (intel_irqs_enabled(dev_priv))
> + if (intel_irqs_enabled(dev_priv)) {
> + vlv_display_irq_reset(dev_priv);
>   vlv_display_irq_postinstall(dev_priv);
> + }
>  }
>  
>  void valleyview_disable_display_irqs(struct drm_i915_private
> *dev_priv)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Move vlv/chv display irq code to a more logical place

[Imre Deak]

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Reshuffle the code a bit to move the vlv/chv display irq functions
> away
> from the main irq hooks, next to the other sub (de,gt,etc.) hooks.
> 
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 98 ---
> --
>  1 file changed, 49 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 5c6511a5a74b..c119610e2d57 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3285,6 +3285,55 @@ static void gen5_gt_irq_reset(struct
> drm_device *dev)
>   GEN5_IRQ_RESET(GEN6_PM);
>  }
>  
> +static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
> +{
> + enum pipe pipe;
> +
> + i915_hotplug_interrupt_update_locked(dev_priv, 0x,
> 0);
> + I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
> +
> + for_each_pipe(dev_priv, pipe)
> + I915_WRITE(PIPESTAT(pipe), 0x);
> +
> + GEN5_IRQ_RESET(VLV_);
> +
> + dev_priv->irq_mask = ~0;
> +}
> +
> +static void vlv_display_irq_postinstall(struct drm_i915_private
> *dev_priv)
> +{
> + u32 pipestat_mask;
> + u32 iir_mask;
> + enum pipe pipe;
> +
> + pipestat_mask = PIPESTAT_INT_STATUS_MASK |
> + PIPE_FIFO_UNDERRUN_STATUS;
> +
> + for_each_pipe(dev_priv, pipe)
> + I915_WRITE(PIPESTAT(pipe), pipestat_mask);
> + POSTING_READ(PIPESTAT(PIPE_A));
> +
> + pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
> + PIPE_CRC_DONE_INTERRUPT_STATUS;
> +
> + i915_enable_pipestat(dev_priv, PIPE_A,
> PIPE_GMBUS_INTERRUPT_STATUS);
> + for_each_pipe(dev_priv, pipe)
> + i915_enable_pipestat(dev_priv, pipe, pipestat_mask);
> +
> + iir_mask = I915_DISPLAY_PORT_INTERRUPT |
> +    I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
> +    I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
> + if (IS_CHERRYVIEW(dev_priv))
> + iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
> + dev_priv->irq_mask &= ~iir_mask;
> +
> + I915_WRITE(VLV_IIR, iir_mask);
> + I915_WRITE(VLV_IIR, iir_mask);
> + I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
> + I915_WRITE(VLV_IMR, dev_priv->irq_mask);
> + POSTING_READ(VLV_IMR);
> +}
> +
>  /* drm_dma.h hooks
>  */
>  static void ironlake_irq_reset(struct drm_device *dev)
> @@ -3302,21 +3351,6 @@ static void ironlake_irq_reset(struct
> drm_device *dev)
>   ibx_irq_reset(dev);
>  }
>  
> -static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
> -{
> - enum pipe pipe;
> -
> - i915_hotplug_interrupt_update_locked(dev_priv, 0x,
> 0);
> - I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
> -
> - for_each_pipe(dev_priv, pipe)
> - I915_WRITE(PIPESTAT(pipe), 0x);
> -
> - GEN5_IRQ_RESET(VLV_);
> -
> - dev_priv->irq_mask = ~0;
> -}
> -
>  static void valleyview_irq_preinstall(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -3653,40 +3687,6 @@ static int ironlake_irq_postinstall(struct
> drm_device *dev)
>   return 0;
>  }
>  
> -static void vlv_display_irq_postinstall(struct drm_i915_private
> *dev_priv)
> -{
> - u32 pipestat_mask;
> - u32 iir_mask;
> - enum pipe pipe;
> -
> - pipestat_mask = PIPESTAT_INT_STATUS_MASK |
> - PIPE_FIFO_UNDERRUN_STATUS;
> -
> - for_each_pipe(dev_priv, pipe)
> - I915_WRITE(PIPESTAT(pipe), pipestat_mask);
> - POSTING_READ(PIPESTAT(PIPE_A));
> -
> - pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
> - PIPE_CRC_DONE_INTERRUPT_STATUS;
> -
> - i915_enable_pipestat(dev_priv, PIPE_A,
> PIPE_GMBUS_INTERRUPT_STATUS);
> - for_each_pipe(dev_priv, pipe)
> -   i915_enable_pipestat(dev_priv, pipe,
> pipestat_mask);
> -
> - iir_mask = I915_DISPLAY_PORT_INTERRUPT |
> -    I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
> -    I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
> - if (IS_CHERRYVIEW(dev_priv))
> - iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
> - dev_priv->irq_mask &= ~iir_mask;
> -
> - I915_WRITE(VLV_IIR, iir_mask);
> - I915_WRITE(VLV_IIR, iir_mask);
> - I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
> - I915_WRITE(VLV_IMR, dev_priv->irq_mask);
> - POSTING_READ(VLV_IMR);
> -}
> -
>  void valleyview_enable_display_irqs(struct drm_i915_private
> *dev_priv)
>  {
>   assert_spin_locked(_priv->irq_lock);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Skip display irq setup if display irqs aren't flagged as enabled

[Imre Deak]

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> During runtime PM we'll be reinitializing interrupt support from the
> ground up. However since the display power well will be off at that
> time, well end up with a ton of unclaimed register accesses from the
> display irq setup. Since we turned off the power well already before
> runtime suspend, we've flagged display irqs as disabled during runtime
> PM transitions. So we can just check that flag to see if we should do
> skip display irqs during irq setup.
> 
> During driver load display irqs will be flagged as enabled since we've
> turned on the power well already, however the power well code will have
> skipped the display irq setup since irq support as a whole wasn't yet
> enabled when the power well was enabled. So we'll want to do the display
> irq setup in that case.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index a1239fedc086..5c6511a5a74b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3326,7 +3326,8 @@ static void valleyview_irq_preinstall(struct
> drm_device *dev)
>   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
>  
>   spin_lock_irq(_priv->irq_lock);
> - vlv_display_irq_reset(dev_priv);
> + if (dev_priv->display_irqs_enabled)
> + vlv_display_irq_reset(dev_priv);
>   spin_unlock_irq(_priv->irq_lock);
>  }
>  
> @@ -3403,7 +3404,8 @@ static void cherryview_irq_preinstall(struct
> drm_device *dev)
>   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
>  
>   spin_lock_irq(_priv->irq_lock);
> - vlv_display_irq_reset(dev_priv);
> + if (dev_priv->display_irqs_enabled)
> + vlv_display_irq_reset(dev_priv);
>   spin_unlock_irq(_priv->irq_lock);
>  }
>  
> @@ -3725,7 +3727,8 @@ static int valleyview_irq_postinstall(struct
> drm_device *dev)
>  #endif
>  
>   spin_lock_irq(_priv->irq_lock);
> - vlv_display_irq_postinstall(dev_priv);
> + if (dev_priv->display_irqs_enabled)
> + vlv_display_irq_postinstall(dev_priv);
>   spin_unlock_irq(_priv->irq_lock);
>  
>   I915_WRITE(VLV_MASTER_IER, MASTER_INTERRUPT_ENABLE);
> @@ -3831,7 +3834,8 @@ static int cherryview_irq_postinstall(struct
> drm_device *dev)
>   gen8_gt_irq_postinstall(dev_priv);
>  
>   spin_lock_irq(_priv->irq_lock);
> - vlv_display_irq_postinstall(dev_priv);
> + if (dev_priv->display_irqs_enabled)
> + vlv_display_irq_postinstall(dev_priv);
>   spin_unlock_irq(_priv->irq_lock);
>  
>   I915_WRITE(GEN8_MASTER_IRQ, MASTER_INTERRUPT_ENABLE);
> @@ -3864,7 +3868,8 @@ static void valleyview_irq_uninstall(struct
> drm_device *dev)
>   I915_WRITE(HWSTAM, 0x);
>  
>   spin_lock_irq(_priv->irq_lock);
> - vlv_display_irq_reset(dev_priv);
> + if (dev_priv->display_irqs_enabled)
> + vlv_display_irq_reset(dev_priv);
>   spin_unlock_irq(_priv->irq_lock);
>  }
>  
> @@ -3883,7 +3888,8 @@ static void cherryview_irq_uninstall(struct
> drm_device *dev)
>   GEN5_IRQ_RESET(GEN8_PCU_);
>  
>   spin_lock_irq(_priv->irq_lock);
> - vlv_display_irq_reset(dev_priv);
> + if (dev_priv->display_irqs_enabled)
> + vlv_display_irq_reset(dev_priv);
>   spin_unlock_irq(_priv->irq_lock);
>  }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix up vlv/chv display irq setup

[Imre Deak]

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The vlv/chv display irq setup was a bit of mess after I ran out of steam
> when working on it last. Fix it up so that we just have a _reset() and
> _postinstall() hooks for the display irqs, and use those consistently.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 102 
> ++--
>  1 file changed, 24 insertions(+), 78 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 1d21ebfffd4d..a1239fedc086 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3306,13 +3306,15 @@ static void vlv_display_irq_reset(struct 
> drm_i915_private *dev_priv)
>  {
>   enum pipe pipe;
>  
> - i915_hotplug_interrupt_update(dev_priv, 0x, 0);
> + i915_hotplug_interrupt_update_locked(dev_priv, 0x, 0);
>   I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
>  
>   for_each_pipe(dev_priv, pipe)
>   I915_WRITE(PIPESTAT(pipe), 0x);

Since vlv_display_irq_reset() will be used in place
of valleyview_display_irqs_uninstall()/i915_disable_pipestat()
we'll leave now stale bits in pipestat_irq_mask[pipe]. It's not a
problem since display_irqs_enabled effectively masks these bits, but
for consistency I'd clear them.

The same goes for clearing PIPE_FIFO_UNDERRUN_STATUS.

With that:
Reviewed-by: Imre Deak 

>  
>   GEN5_IRQ_RESET(VLV_);
> +
> + dev_priv->irq_mask = ~0;
>  }



>  
>  static void valleyview_irq_preinstall(struct drm_device *dev)
> @@ -3323,7 +3325,9 @@ static void valleyview_irq_preinstall(struct drm_device 
> *dev)
>  
>   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
>  
> + spin_lock_irq(_priv->irq_lock);
>   vlv_display_irq_reset(dev_priv);
> + spin_unlock_irq(_priv->irq_lock);
>  }
>  
>  static void gen8_gt_irq_reset(struct drm_i915_private *dev_priv)
> @@ -3398,7 +3402,9 @@ static void cherryview_irq_preinstall(struct drm_device 
> *dev)
>  
>   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
>  
> + spin_lock_irq(_priv->irq_lock);
>   vlv_display_irq_reset(dev_priv);
> + spin_unlock_irq(_priv->irq_lock);
>  }
>  
>  static u32 intel_hpd_enabled_irqs(struct drm_device *dev,
> @@ -3645,7 +3651,7 @@ static int ironlake_irq_postinstall(struct drm_device 
> *dev)
>   return 0;
>  }
>  
> -static void valleyview_display_irqs_install(struct drm_i915_private 
> *dev_priv)
> +static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
>  {
>   u32 pipestat_mask;
>   u32 iir_mask;
> @@ -3679,40 +3685,6 @@ static void valleyview_display_irqs_install(struct 
> drm_i915_private *dev_priv)
>   POSTING_READ(VLV_IMR);
>  }
>  
> -static void valleyview_display_irqs_uninstall(struct drm_i915_private 
> *dev_priv)
> -{
> - u32 pipestat_mask;
> - u32 iir_mask;
> - enum pipe pipe;
> -
> - iir_mask = I915_DISPLAY_PORT_INTERRUPT |
> -    I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
> -    I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
> - if (IS_CHERRYVIEW(dev_priv))
> - iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
> -
> - dev_priv->irq_mask |= iir_mask;
> - I915_WRITE(VLV_IMR, dev_priv->irq_mask);
> - I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
> - I915_WRITE(VLV_IIR, iir_mask);
> - I915_WRITE(VLV_IIR, iir_mask);
> - POSTING_READ(VLV_IIR);
> -
> - pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
> - PIPE_CRC_DONE_INTERRUPT_STATUS;
> -
> - i915_disable_pipestat(dev_priv, PIPE_A, PIPE_GMBUS_INTERRUPT_STATUS);
> - for_each_pipe(dev_priv, pipe)
> - i915_disable_pipestat(dev_priv, pipe, pipestat_mask);
> -
> - pipestat_mask = PIPESTAT_INT_STATUS_MASK |
> - PIPE_FIFO_UNDERRUN_STATUS;
> -
> - for_each_pipe(dev_priv, pipe)
> - I915_WRITE(PIPESTAT(pipe), pipestat_mask);
> - POSTING_READ(PIPESTAT(PIPE_A));
> -}
> -
>  void valleyview_enable_display_irqs(struct drm_i915_private *dev_priv)
>  {
>   assert_spin_locked(_priv->irq_lock);
> @@ -3723,7 +3695,7 @@ void valleyview_enable_display_irqs(struct 
> drm_i915_private *dev_priv)
>   dev_priv->display_irqs_enabled = true;
>  
>   if (intel_irqs_enabled(dev_priv))
> - valleyview_display_irqs_install(dev_priv);
> + vlv_display_irq_postinstall(dev_priv);
>  }
>  
>  void valleyview_disable_display_irqs(struct drm_i915_private *dev_priv)
> @@ -3736,36 +3708,14 @@ void valleyview_disable_display_irqs(struct 
> drm_i915_private *dev_priv)
>   dev_priv->display_irqs_enabled = false;
>  
>   if (intel_irqs_enabled(dev_priv))
> - valleyview_display_irqs_uninstall(dev_priv);
> + vlv_display_irq_reset(dev_priv);
>  }
>  
> -static 

[Intel-gfx] [PATCH v3 1/3] drm/edid: Add drm_edid_get_monitor_name()

[Jim Bride]

In order to include monitor name information in debugfs
output we needed to add a function that would extract the
monitor name from the EDID, and that function needed to
reside in the file  where the rest of the EDID helper
functions are implemented.

v2: Refactor to have drm_edid_get_monitor_name() and drm_edid_to_eld()
use a common helper function to extract the monitor name from the
edid. [Jani] + rebase.

v3: Minor changes suggested by Jani + rebase.

cc: dri-de...@lists.freedesktop.org
cc: Jani Nikula 
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/drm_edid.c | 51 ++
 include/drm/drm_crtc.h |  2 ++
 2 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 558ef9f..da30ce3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3293,6 +3293,46 @@ monitor_name(struct detailed_timing *t, void *data)
*(u8 **)data = t->data.other_data.data.str.str;
 }
 
+static int get_monitor_name(struct edid *edid, char name[13])
+{
+   char *edid_name = NULL;
+   int mnl;
+
+   if (!edid || !name)
+   return 0;
+
+   drm_for_each_detailed_block((u8 *)edid, monitor_name, _name);
+   for (mnl = 0; edid_name && mnl < 13; mnl++) {
+   if (edid_name[mnl] == 0x0a)
+   break;
+
+   name[mnl] = edid_name[mnl];
+   }
+
+   return mnl;
+}
+
+/**
+ * drm_edid_get_monitor_name - fetch the monitor name from the edid
+ * @edid: monitor EDID information
+ * @name: pointer to a character array to hold the name of the monitor
+ * @bufsize: The size of the name buffer (should be at least 13 chars.)
+ *
+ */
+void drm_edid_get_monitor_name(struct edid *edid, char *name, int bufsize)
+{
+   int name_length = -1;
+   char buf[13];
+   
+   if (bufsize <= 0)
+   return;
+
+   name_length = min(get_monitor_name(edid, buf), bufsize - 1);
+   memcpy(name, buf, name_length);
+   name[name_length] = '\0';
+}
+EXPORT_SYMBOL(drm_edid_get_monitor_name);
+
 /**
  * drm_edid_to_eld - build ELD from EDID
  * @connector: connector corresponding to the HDMI/DP sink
@@ -3306,7 +3346,6 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
 {
uint8_t *eld = connector->eld;
u8 *cea;
-   u8 *name;
u8 *db;
int total_sad_count = 0;
int mnl;
@@ -3320,14 +3359,8 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
return;
}
 
-   name = NULL;
-   drm_for_each_detailed_block((u8 *)edid, monitor_name, );
-   /* max: 13 bytes EDID, 16 bytes ELD */
-   for (mnl = 0; name && mnl < 13; mnl++) {
-   if (name[mnl] == 0x0a)
-   break;
-   eld[20 + mnl] = name[mnl];
-   }
+   mnl = get_monitor_name(edid, eld + 20);
+
eld[4] = (cea[1] << 5) | mnl;
DRM_DEBUG_KMS("ELD monitor %s\n", eld + 20);
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8cb377c..6d46842 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -2500,6 +2500,8 @@ extern int drm_edid_header_is_valid(const u8 *raw_edid);
 extern bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
 bool *edid_corrupt);
 extern bool drm_edid_is_valid(struct edid *edid);
+extern void drm_edid_get_monitor_name(struct edid *edid, char *name,
+ int buflen);
 
 extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device 
*dev,
 char topology[8]);
-- 
2.5.0

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

[Intel-gfx] [PATCH v3 3/3] drm/i915/dp/mst: Add source port info to debugfs output

[Jim Bride]

Modify the debugfs output for i915_dp_mst_info to list the source port for
the DP MST topology in question.

v2: rebase
v3: rebase

cc: Jani Nikula 
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9640738..644e80b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3446,7 +3446,8 @@ static int i915_dp_mst_info(struct seq_file *m, void 
*unused)
intel_dig_port = enc_to_dig_port(encoder);
if (!intel_dig_port->dp.can_mst)
continue;
-
+   seq_printf(m, "MST Source Port %c\n",
+  port_name(intel_dig_port->port));
drm_dp_mst_dump_topology(m, _dig_port->dp.mst_mgr);
}
drm_modeset_unlock_all(dev);
-- 
2.5.0

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

[Intel-gfx] [PATCH v3 2/3] drm/dp/mst: Enhance DP MST debugfs output

[Jim Bride]

Add some additional information (input vs. output port, sink associated
with VC, peer device type, max number of VCs supported) and ensure that
any embedded '\0' characters in a branch device's devid string are not
written to debugfs.

v2: Rebase + change drm_edid_get_monitor_name() call to reflect new
signature.

v3: Minor changes suggested by Jani + rebase.

cc: dri-de...@lists.freedesktop.org
cc: Jani Nikula 
Signed-off-by: Jim Bride 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 29 -
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 27fbd79..06d8b0a 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2729,7 +2729,7 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
 
seq_printf(m, "%smst: %p, %d\n", prefix, mstb, mstb->num_ports);
list_for_each_entry(port, >ports, next) {
-   seq_printf(m, "%sport: %d: ddps: %d ldps: %d, sdp: %d/%d, %p, 
conn: %p\n", prefix, port->port_num, port->ddps, port->ldps, 
port->num_sdp_streams, port->num_sdp_stream_sinks, port, port->connector);
+   seq_printf(m, "%sport: %d: input: %d: pdt: %d, ddps: %d ldps: 
%d, sdp: %d/%d, %p, conn: %p\n", prefix, port->port_num, port->input, 
port->pdt, port->ddps, port->ldps, port->num_sdp_streams, 
port->num_sdp_stream_sinks, port, port->connector);
if (port->mstb)
drm_dp_mst_dump_mstb(m, port->mstb);
}
@@ -2750,6 +2750,16 @@ static bool dump_dp_payload_table(struct 
drm_dp_mst_topology_mgr *mgr,
return false;
 }
 
+static void fetch_monitor_name(struct drm_dp_mst_topology_mgr *mgr,
+  struct drm_dp_mst_port *port, char *name,
+  int namelen)
+{
+   struct edid *mst_edid;
+
+   mst_edid = drm_dp_mst_get_edid(port->connector, mgr, port);
+   drm_edid_get_monitor_name(mst_edid, name, namelen);
+}
+
 /**
  * drm_dp_mst_dump_topology(): dump topology to seq file.
  * @m: seq_file to dump output to
@@ -2762,6 +2772,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
 {
int i;
struct drm_dp_mst_port *port;
+
mutex_lock(>lock);
if (mgr->mst_primary)
drm_dp_mst_dump_mstb(m, mgr->mst_primary);
@@ -2770,14 +2781,21 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
mutex_unlock(>lock);
 
mutex_lock(>payload_lock);
-   seq_printf(m, "vcpi: %lx %lx\n", mgr->payload_mask, mgr->vcpi_mask);
+   seq_printf(m, "vcpi: %lx %lx %d\n", mgr->payload_mask, mgr->vcpi_mask,
+   mgr->max_payloads);
 
for (i = 0; i < mgr->max_payloads; i++) {
if (mgr->proposed_vcpis[i]) {
+   char name[14];
+
port = container_of(mgr->proposed_vcpis[i], struct 
drm_dp_mst_port, vcpi);
-   seq_printf(m, "vcpi %d: %d %d %d\n", i, port->port_num, 
port->vcpi.vcpi, port->vcpi.num_slots);
+   fetch_monitor_name(mgr, port, name, sizeof(name));
+   seq_printf(m, "vcpi %d: %d %d %d sink name: %s\n", i,
+  port->port_num, port->vcpi.vcpi,
+  port->vcpi.num_slots,
+  (*name != 0) ? name :  "Unknown");
} else
-   seq_printf(m, "vcpi %d:unsed\n", i);
+   seq_printf(m, "vcpi %d:unused\n", i);
}
for (i = 0; i < mgr->max_payloads; i++) {
seq_printf(m, "payload %d: %d, %d, %d\n",
@@ -2817,8 +2835,9 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
for (i = 0; i < 0x3; i++)
seq_printf(m, "%02x", buf[i]);
seq_printf(m, " devid: ");
-   for (i = 0x3; i < 0x8; i++)
+   for (i = 0x3; i < 0x8 && buf[i]; i++)
seq_printf(m, "%c", buf[i]);
+
seq_printf(m, " revision: hw: %x.%x sw: %x.%x", buf[0x9] >> 4, 
buf[0x9] & 0xf, buf[0xa], buf[0xb]);
seq_printf(m, "\n");
bret = dump_dp_payload_table(mgr, buf);
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Remove "VLV magic" from irq setup

[Ville Syrjälä]

On Mon, Apr 11, 2016 at 06:20:04PM +0300, Imre Deak wrote:
> On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > No clue what this is supposed to achieve. I think it's been there
> > since
> > the very beginning, so presumably some kind of kludge for very early
> > silicon. Let's just throw it out.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 6 --
> >  1 file changed, 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 679f08c944ef..1d21ebfffd4d 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -3319,12 +3319,6 @@ static void valleyview_irq_preinstall(struct
> > drm_device *dev)
> >  {
> >     struct drm_i915_private *dev_priv = dev->dev_private;
> >  
> > -   /* VLV magic */
> > -   I915_WRITE(VLV_IMR, 0);
> > -   I915_WRITE(RING_IMR(RENDER_RING_BASE), 0);
> > -   I915_WRITE(RING_IMR(GEN6_BSD_RING_BASE), 0);
> > -   I915_WRITE(RING_IMR(BLT_RING_BASE), 0);
> > -
> 
> AFAICS this would also leave the ring interrupts unmasked before we
> called ring->get_irq(), so at least the change is a fix for that.

On a related note, in ringbuffer mode we don't actually make sure they're
masked. The execlist code has explicit ring IMR initialization.

> I
> haven't found any explanation for the above either, so I guess the best
> we can do at this point is to see if things continue to work without
> it:
> 
> Reviewed-by: Imre Deak 
> 
> >     gen5_gt_irq_reset(dev);
> >  
> >     I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make GMBUS timeout message DRM_DEBUG_KMS

[Ville Syrjälä]

On Mon, Apr 11, 2016 at 09:19:40AM +0100, Chris Wilson wrote:
> On Mon, Apr 11, 2016 at 10:29:29AM +0300, Ville Syrjälä wrote:
> > On Mon, Mar 07, 2016 at 05:57:00PM +0200, ville.syrj...@linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > There's no real reason the user should care that we're about to fall
> > > back to bitbanging, so let's change the message from DRM_INFO to
> > > DRM_DEBUG_KMS.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94890
> 
> Reviewed-by: Chris Wilson 
> 
> KMS or DRIVER though? GMBUS is now independent of KMS, so probably worth
> keeping it separate.

All the other debug message in the gmbus code are KMS. Keeping to the
party line seems best to me.

-- 
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 01/10] drm/i915: Remove "VLV magic" from irq setup

[Imre Deak]

On ma, 2016-04-11 at 16:56 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> No clue what this is supposed to achieve. I think it's been there
> since
> the very beginning, so presumably some kind of kludge for very early
> silicon. Let's just throw it out.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 679f08c944ef..1d21ebfffd4d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3319,12 +3319,6 @@ static void valleyview_irq_preinstall(struct
> drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> - /* VLV magic */
> - I915_WRITE(VLV_IMR, 0);
> - I915_WRITE(RING_IMR(RENDER_RING_BASE), 0);
> - I915_WRITE(RING_IMR(GEN6_BSD_RING_BASE), 0);
> - I915_WRITE(RING_IMR(BLT_RING_BASE), 0);
> -

AFAICS this would also leave the ring interrupts unmasked before we
called ring->get_irq(), so at least the change is a fix for that. I
haven't found any explanation for the above either, so I guess the best
we can do at this point is to see if things continue to work without
it:

Reviewed-by: Imre Deak 

>   gen5_gt_irq_reset(dev);
>  
>   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/core: Add drm_accurate_vblank_count_and_time, v2.

[Ville Syrjälä]

On Mon, Apr 11, 2016 at 05:06:24PM +0200, Maarten Lankhorst wrote:
> Op 11-04-16 om 16:43 schreef Ville Syrjälä:
> > On Mon, Apr 11, 2016 at 11:42:57AM +0200, Maarten Lankhorst wrote:
> >> This function is useful for gen2 intel devices which have no frame
> >> counter, but need a way to determine the current vblank count without
> >> racing with the vblank interrupt handler.
> >>
> >> intel_pipe_update_start checks if no vblank interrupt will occur
> >> during vblank evasion, but cannot check whether the vblank handler has
> >> run to completion. This function uses the timestamps to determine
> >> when the last vblank has happened, and interpolates from there.
> >>
> >> Changes since v1:
> >> - Take vblank_time_lock and don't use drm_vblank_count_and_time.
> >>
> >> Cc: Mario Kleiner 
> >> Cc: Ville Syrjälä 
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/drm_irq.c | 31 +++
> >>  include/drm/drmP.h|  2 ++
> >>  2 files changed, 33 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> >> index 3c1a6f18e71c..d3cecc1932e1 100644
> >> --- a/drivers/gpu/drm/drm_irq.c
> >> +++ b/drivers/gpu/drm/drm_irq.c
> >> @@ -303,6 +303,37 @@ static void drm_update_vblank_count(struct drm_device 
> >> *dev, unsigned int pipe,
> >>store_vblank(dev, pipe, diff, _vblank, cur_vblank);
> >>  }
> >>  
> >> +/**
> >> + * drm_accurate_vblank_count_and_time - retrieve the master vblank counter
> >> + * @crtc: which counter to retrieve
> >> + * @tv_ret: last time counter was updated
> >> + *
> >> + * This function is similar to @drm_update_vblank_count_and_time but
> >> + * this function interpolates to handle a race with vblank irq's, and
> >> + * is only useful for crtc's that have no hw vblank counter.
> >> + */
> >> +
> >> +u32 drm_accurate_vblank_count_and_time(struct drm_crtc *crtc,
> >> + struct timeval *tv_ret)
> >> +{
> >> +  struct drm_device *dev = crtc->dev;
> >> +  u32 vblank, pipe = drm_crtc_index(crtc);
> >> +  unsigned long flags;
> >> +
> >> +  WARN(dev->max_vblank_count, "This function is only useful when a hw 
> >> counter is unavailable.");
> > It's useful on everything if you actually want to trust the
> > software counter to not be stale.
> >
> >> +
> >> +  spin_lock_irqsave(>vblank_time_lock, flags);
> >> +  drm_update_vblank_count(dev, pipe, 0);
> >> +
> >> +  vblank = dev->vblank[pipe].count;
> >> +  *tv_ret = vblanktimestamp(dev, pipe, vblank);
> > Do we have a user in mind that would care about the timestamp?
> >
> No, I guess allowing a NULL pointer for tv_ret might help.

Or just killing the entire parameter.

-- 
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 v3] test/gem_mocs_settings: Testing MOCS register settings

[Chris Wilson]

On Mon, Apr 11, 2016 at 04:02:17PM +0100, Peter Antoine wrote:
> >>+   for (index = 0, offset = 0; index < size; index++, offset += 4)
> >>+   {
> >>+   batch[offset]   = MI_STORE_REGISTER_MEM_64_BIT_ADDR;
> >>+   batch[offset+1] = reg_base + (index * sizeof(uint32_t));
> >>+   batch[offset+2] = index * sizeof(uint32_t); /* reloc */
> >>+   batch[offset+3] = 0;
> >>+
> >>+   reloc[index].offset = (offset + 2) * sizeof(uint32_t);
> >>+   reloc[index].delta = index * sizeof(uint32_t);
> >>+   reloc[index].target_handle = dst_handle;
> >>+   reloc[index].write_domain = I915_GEM_DOMAIN_RENDER;
> >
> >Will cause an -EINVAL as you are specifing a write_domain but not the
> >corresponding read_domain.
> Removed.

I hope you meant added the missing read_domains!

> (Did not cause an error when tested)

Hmm, ok we don't actually warn about that!

> >>+static void do_read_registers(int fd,
> >>+ uint32_t ctx_id,
> >>+ uint32_t dst_handle,
> >>+ uint32_t reg_base,
> >>+ uint32_t size,
> >>+ uint32_t engine_id)
> >>+{
> >>+   gem_execbuf(fd, );
> >>+   gem_wait(fd, dst_handle, _ns);
> >
> >As mentioned earlier, tried to avoid manual wait/sync so that we stress
> >the kernel harder to do the right thing. Sometimes the sync is required
> >as part of the test, but only rarely and should be well documented.
> replaced with set_domain.
> 
> >
> >>+   gem_close(fd, handle);
> >>+}
> >
> >>+static void check_control_registers(int fd,
> >>+   const struct intel_execution_engine *engine,
> >>+   uint32_t ctx_id,
> >>+   bool dirty)
> >>+{
> >>+   uint32_t dst_handle = gem_create(fd, 4096);
> >>+   uint32_t reg_base  = get_engine_base(engine->exec_id | engine->flags);
> >>+   uint32_t *read_regs;
> >>+   struct mocs_table table;
> >>+
> >>+   igt_assert(get_mocs_settings(intel_get_drm_devid(fd), , dirty));
> >>+
> >>+   do_read_registers(fd,
> >>+ ctx_id,
> >>+ dst_handle,
> >>+ reg_base,
> >>+ table.size,
> >>+ engine->exec_id | engine->flags);
> >>+
> >>+   read_regs = gem_mmap__cpu(fd, dst_handle, 0, 4096, PROT_READ);
> >
> >Here you need the corresponding
> >gem_set_comdin(fd, dst_handle, DOMAIN_CPU, 0);
> >and in check_l3cc_registers.
> Added into do_read_registers() so should handle both.

But less explicit and doesn't document the code as well. Move the
set-domain next to the usage of dst_handle in the CPU domain.
-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 5/6] drm/i915: Unduplicate CHV pre-encoder enabling phy logic

[Ville Syrjälä]

On Fri, Apr 08, 2016 at 06:31:45PM +0300, Ander Conselvan de Oliveira wrote:
> The only difference between the DP and HDMI versions was the lane count.
> Since lane_count is now set appropriately for HDMI too, get rid of the
> duplication and move this to intel_dpio_phy.c
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  2 +
>  drivers/gpu/drm/i915/intel_dp.c   | 84 +--
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 93 
> +++
>  drivers/gpu/drm/i915/intel_hdmi.c | 69 +-
>  4 files changed, 99 insertions(+), 149 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7b2f453..e1b2f48 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3511,6 +3511,8 @@ void chv_set_phy_signal_level(struct intel_encoder 
> *encoder,
>  void chv_data_lane_soft_reset(struct intel_encoder *encoder,
> bool reset);
>  void chv_phy_pre_pll_enable(struct intel_encoder *encoder);
> +void chv_phy_pre_encoder_enable(struct intel_encoder *encoder);
> +void chv_phy_release_cl2_override(struct intel_encoder *encoder);
>  
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fb0c9c5..8735738 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2851,91 +2851,11 @@ static void vlv_dp_pre_pll_enable(struct 
> intel_encoder *encoder)
>  
>  static void chv_pre_enable_dp(struct intel_encoder *encoder)
>  {
> - struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> - struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = encoder->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc =
> - to_intel_crtc(encoder->base.crtc);
> - enum dpio_channel ch = vlv_dport_to_channel(dport);
> - int pipe = intel_crtc->pipe;
> - int data, i, stagger;
> - u32 val;
> -
> - mutex_lock(_priv->sb_lock);
> -
> - /* allow hardware to manage TX FIFO reset source */
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
> - val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
> -
> - if (intel_crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
> - val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
> - }
> -
> - /* Program Tx lane latency optimal setting*/
> - for (i = 0; i < intel_crtc->config->lane_count; i++) {
> - /* Set the upar bit */
> - if (intel_crtc->config->lane_count == 1)
> - data = 0x0;
> - else
> - data = (i == 1) ? 0x0 : 0x1;
> - vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
> - data << DPIO_UPAR_SHIFT);
> - }
> -
> - /* Data lane stagger programming */
> - if (intel_crtc->config->port_clock > 27)
> - stagger = 0x18;
> - else if (intel_crtc->config->port_clock > 135000)
> - stagger = 0xd;
> - else if (intel_crtc->config->port_clock > 67500)
> - stagger = 0x7;
> - else if (intel_crtc->config->port_clock > 33750)
> - stagger = 0x4;
> - else
> - stagger = 0x2;
> -
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
> - val |= DPIO_TX2_STAGGER_MASK(0x1f);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
> -
> - if (intel_crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
> - val |= DPIO_TX2_STAGGER_MASK(0x1f);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
> - }
> -
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW12(ch),
> -DPIO_LANESTAGGER_STRAP(stagger) |
> -DPIO_LANESTAGGER_STRAP_OVRD |
> -DPIO_TX1_STAGGER_MASK(0x1f) |
> -DPIO_TX1_STAGGER_MULT(6) |
> -DPIO_TX2_STAGGER_MULT(0));
> -
> - if (intel_crtc->config->lane_count > 2) {
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW12(ch),
> -DPIO_LANESTAGGER_STRAP(stagger) |
> -DPIO_LANESTAGGER_STRAP_OVRD |
> -DPIO_TX1_STAGGER_MASK(0x1f) |
> -DPIO_TX1_STAGGER_MULT(7) |
> -DPIO_TX2_STAGGER_MULT(5));
> - }
> -
> - /* Deassert data lane reset */
> - 

Re: [Intel-gfx] [PATCH 2/6] drm/i915: Unduplicate CHV signal level code

[Ville Syrjälä]

On Fri, Apr 08, 2016 at 06:31:42PM +0300, Ander Conselvan de Oliveira wrote:
> The code for programming voltage swing and emphasis was duplicated
> between DP and HDMI code. Move that to a new file, intel_dpio_phy.c.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/i915_drv.h   |   5 ++
>  drivers/gpu/drm/i915/intel_dp.c   | 103 ++--
>  drivers/gpu/drm/i915/intel_dpio_phy.c | 122 
> ++
>  drivers/gpu/drm/i915/intel_hdmi.c |  72 +---
>  5 files changed, 136 insertions(+), 167 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_dpio_phy.c
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7ffb51b..eb45e28 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -57,6 +57,7 @@ i915-y += intel_audio.o \
> intel_bios.o \
> intel_color.o \
> intel_display.o \
> +   intel_dpio_phy.o \
> intel_dpll_mgr.o \
> intel_fbc.o \
> intel_fifo_underrun.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4ebd3ff..3c393e3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3504,6 +3504,11 @@ void intel_sbi_write(struct drm_i915_private 
> *dev_priv, u16 reg, u32 value,
>  u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
>  void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>  
> +/* intel_dpio_phy.c */
> +void chv_set_phy_signal_level(struct intel_encoder *encoder,
> +   u32 deemph_reg_value, u32 margin_reg_value,
> +   bool uniq_trans_scale);
> +
>  int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
>  int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index da0c3d2..5ba72b0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3339,23 +3339,12 @@ static uint32_t vlv_signal_levels(struct intel_dp 
> *intel_dp)
>   return 0;
>  }
>  
> -static bool chv_need_uniq_trans_scale(uint8_t train_set)
> -{
> - return (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) == 
> DP_TRAIN_PRE_EMPH_LEVEL_0 &&
> - (train_set & DP_TRAIN_VOLTAGE_SWING_MASK) == 
> DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
> -}
> -
>  static uint32_t chv_signal_levels(struct intel_dp *intel_dp)
>  {
> - struct drm_device *dev = intel_dp_to_dev(intel_dp);
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> - struct intel_crtc *intel_crtc = to_intel_crtc(dport->base.base.crtc);
> - u32 deemph_reg_value, margin_reg_value, val;
> + struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
> + u32 deemph_reg_value, margin_reg_value;
> + bool uniq_trans_scale = false;
>   uint8_t train_set = intel_dp->train_set[0];
> - enum dpio_channel ch = vlv_dport_to_channel(dport);
> - enum pipe pipe = intel_crtc->pipe;
> - int i;
>  
>   switch (train_set & DP_TRAIN_PRE_EMPHASIS_MASK) {
>   case DP_TRAIN_PRE_EMPH_LEVEL_0:
> @@ -3375,7 +3364,7 @@ static uint32_t chv_signal_levels(struct intel_dp 
> *intel_dp)
>   case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
>   deemph_reg_value = 128;
>   margin_reg_value = 154;
> - /* FIXME extra to set for 1200 */
> + uniq_trans_scale = true;
>   break;
>   default:
>   return 0;
> @@ -3427,88 +3416,8 @@ static uint32_t chv_signal_levels(struct intel_dp 
> *intel_dp)
>   return 0;
>   }
>  
> - mutex_lock(_priv->sb_lock);
> -
> - /* Clear calc init */
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
> - val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
> - val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
> - val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
> -
> - if (intel_crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
> - val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | 
> DPIO_PCS_SWING_CALC_TX1_TX3);
> - val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
> - val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
> - }
> -
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW9(ch));
> - val &= ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
> - val |= DPIO_PCS_TX1MARGIN_000 | 

Re: [Intel-gfx] [PATCH v2] drm/core: Add drm_accurate_vblank_count_and_time, v2.

[Maarten Lankhorst]

Op 11-04-16 om 16:43 schreef Ville Syrjälä:
> On Mon, Apr 11, 2016 at 11:42:57AM +0200, Maarten Lankhorst wrote:
>> This function is useful for gen2 intel devices which have no frame
>> counter, but need a way to determine the current vblank count without
>> racing with the vblank interrupt handler.
>>
>> intel_pipe_update_start checks if no vblank interrupt will occur
>> during vblank evasion, but cannot check whether the vblank handler has
>> run to completion. This function uses the timestamps to determine
>> when the last vblank has happened, and interpolates from there.
>>
>> Changes since v1:
>> - Take vblank_time_lock and don't use drm_vblank_count_and_time.
>>
>> Cc: Mario Kleiner 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_irq.c | 31 +++
>>  include/drm/drmP.h|  2 ++
>>  2 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index 3c1a6f18e71c..d3cecc1932e1 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -303,6 +303,37 @@ static void drm_update_vblank_count(struct drm_device 
>> *dev, unsigned int pipe,
>>  store_vblank(dev, pipe, diff, _vblank, cur_vblank);
>>  }
>>  
>> +/**
>> + * drm_accurate_vblank_count_and_time - retrieve the master vblank counter
>> + * @crtc: which counter to retrieve
>> + * @tv_ret: last time counter was updated
>> + *
>> + * This function is similar to @drm_update_vblank_count_and_time but
>> + * this function interpolates to handle a race with vblank irq's, and
>> + * is only useful for crtc's that have no hw vblank counter.
>> + */
>> +
>> +u32 drm_accurate_vblank_count_and_time(struct drm_crtc *crtc,
>> +   struct timeval *tv_ret)
>> +{
>> +struct drm_device *dev = crtc->dev;
>> +u32 vblank, pipe = drm_crtc_index(crtc);
>> +unsigned long flags;
>> +
>> +WARN(dev->max_vblank_count, "This function is only useful when a hw 
>> counter is unavailable.");
> It's useful on everything if you actually want to trust the
> software counter to not be stale.
>
>> +
>> +spin_lock_irqsave(>vblank_time_lock, flags);
>> +drm_update_vblank_count(dev, pipe, 0);
>> +
>> +vblank = dev->vblank[pipe].count;
>> +*tv_ret = vblanktimestamp(dev, pipe, vblank);
> Do we have a user in mind that would care about the timestamp?
>
No, I guess allowing a NULL pointer for tv_ret might help.

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

Re: [Intel-gfx] [PATCH v3] test/gem_mocs_settings: Testing MOCS register settings

[Peter Antoine]

On Mon, 11 Apr 2016, Chris Wilson wrote:


On Mon, Apr 11, 2016 at 01:51:25PM +0100, Peter Antoine wrote:

The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second set controls
the L3 policy. The two sets use the same index.

The RCS registers and the L3CC registers are stored in the RCS context.

The test checks that the registers are correct by checking the values by
directly reading them via MMIO, then again it tests them by reading them
from within a batch buffer. RCS engine is tested last as it programs the
registers via a batch buffer and this will invalidate the test for
workloads that don't use the render ring or don't run a render batch
first.

v2: Reorganised the structure.
Added more tests. (Chris Wilson)
v3: Fixed a few bugs. (Chris Wilson)

Signed-off-by: Peter Antoine 
---
 lib/ioctl_wrappers.c  |  13 ++
 lib/ioctl_wrappers.h  |   1 +
 tests/Makefile.sources|   1 +
 tests/gem_mocs_settings.c | 559 ++
 4 files changed, 574 insertions(+)
 create mode 100644 tests/gem_mocs_settings.c

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 076bce8..8d74128 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1382,6 +1382,19 @@ void gem_require_ring(int fd, unsigned ring)
igt_require(gem_has_ring(fd, ring));
 }

+/**
+ * gem_has_mocs:
+ * @fd: open i915 drm file descriptor
+ *
+ * Feature test macro to query whether the device has MOCS registers.
+ * These exist gen 9+.
+ */
+void gem_has_mocs(int fd)


gem_has_mocs() returns bool
gem_require_mocs() calls igt_require() and doesn't return if not
available.


Done.

+{
+   const int gen = intel_gen(intel_get_drm_devid(fd));
+   igt_require(gen >= 9);
+}
+
 /* prime */

 /**
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index d986f61..ebedf1e 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -154,6 +154,7 @@ bool gem_has_softpin(int fd);
 void gem_require_caching(int fd);
 bool gem_has_ring(int fd, unsigned ring);
 void gem_require_ring(int fd, unsigned ring);
+void gem_has_mocs(int fd);

 /* prime */
 struct local_dma_buf_sync {
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 43f232f..d483c9e 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -148,6 +148,7 @@ TESTS_progs = \
gem_lut_handle \
gem_mmap_offset_exhaustion \
gem_media_fill \
+   gem_mocs_settings \
gem_gpgpu_fill \
gem_pin \
gem_reg_read \
diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
new file mode 100644
index 000..03c5089
--- /dev/null
+++ b/tests/gem_mocs_settings.c
@@ -0,0 +1,559 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+/** @file gem_mocs_settings.c
+ *
+ * Check that the MOCs cache settings are valid.
+ */
+
+#include "igt.h"
+#include "igt_gt.h"
+
+#define MAX_NUMBER_MOCS_REGISTERS  (64)
+
+enum {
+   NONE,
+   RESET,
+   SUSPEND,
+   HIBERNATE
+};
+
+#define GEN9_LNCFCMOCS0(0xB020)/* L3 Cache Control 
base */
+#define GEN9_GFX_MOCS_0(0xc800)/* Graphics MOCS base 
register*/
+#define GEN9_MFX0_MOCS_0   (0xc900)/* Media 0 MOCS base register*/
+#define GEN9_MFX1_MOCS_0   (0xcA00)/* Media 1 MOCS base register*/
+#define GEN9_VEBOX_MOCS_0  (0xcB00)/* Video MOCS base register*/
+#define GEN9_BLT_MOCS_0(0xcc00)/* Blitter MOCS base 
register*/
+
+#define ENGINE_GFX (I915_EXEC_RENDER)
+#define ENGINE_MFX0(I915_EXEC_BSD)
+#define ENGINE_MFX0_ALT(I915_EXEC_BSD | 1 << 13)
+#define ENGINE_MFX1(I915_EXEC_BSD | 2 << 13)
+#define ENGINE_BLT 

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

[Tvrtko Ursulin]

On 11/04/16 15:44, Chris Wilson wrote:

On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote:


On 08/04/16 12:11, Chris Wilson wrote:

When called because we have run out of vmap address space, we only need
to recover objects that have vmappings and not all.

v2: Start using is_vmalloc_addr()

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


Reviewed-by: Tvrtko Ursulin 


Having started to use the obj->mapping cache in anger, do you think there
is any left before pushing this part of the puzzle? I'm hitting an
interesting scaling problem with vmalloc's lazy free list (that's a
patch for later!).


Looks ready and useful to me so I vote for merging it.

I can follow up with the LRC reg state when it is in.

Regards,

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

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

[Chris Wilson]

On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote:
> 
> On 08/04/16 12:11, Chris Wilson wrote:
> >When called because we have run out of vmap address space, we only need
> >to recover objects that have vmappings and not all.
> >
> >v2: Start using is_vmalloc_addr()
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >---
> >  drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >  drivers/gpu/drm/i915/i915_gem_shrinker.c | 10 +-
> >  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> Reviewed-by: Tvrtko Ursulin 

Having started to use the obj->mapping cache in anger, do you think there
is any left before pushing this part of the puzzle? I'm hitting an
interesting scaling problem with vmalloc's lazy free list (that's a
patch for later!).
-Chris


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

Re: [Intel-gfx] [PATCH v2] drm/core: Add drm_accurate_vblank_count_and_time, v2.

[Ville Syrjälä]

On Mon, Apr 11, 2016 at 11:42:57AM +0200, Maarten Lankhorst wrote:
> This function is useful for gen2 intel devices which have no frame
> counter, but need a way to determine the current vblank count without
> racing with the vblank interrupt handler.
> 
> intel_pipe_update_start checks if no vblank interrupt will occur
> during vblank evasion, but cannot check whether the vblank handler has
> run to completion. This function uses the timestamps to determine
> when the last vblank has happened, and interpolates from there.
> 
> Changes since v1:
> - Take vblank_time_lock and don't use drm_vblank_count_and_time.
> 
> Cc: Mario Kleiner 
> Cc: Ville Syrjälä 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_irq.c | 31 +++
>  include/drm/drmP.h|  2 ++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 3c1a6f18e71c..d3cecc1932e1 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -303,6 +303,37 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   store_vblank(dev, pipe, diff, _vblank, cur_vblank);
>  }
>  
> +/**
> + * drm_accurate_vblank_count_and_time - retrieve the master vblank counter
> + * @crtc: which counter to retrieve
> + * @tv_ret: last time counter was updated
> + *
> + * This function is similar to @drm_update_vblank_count_and_time but
> + * this function interpolates to handle a race with vblank irq's, and
> + * is only useful for crtc's that have no hw vblank counter.
> + */
> +
> +u32 drm_accurate_vblank_count_and_time(struct drm_crtc *crtc,
> +struct timeval *tv_ret)
> +{
> + struct drm_device *dev = crtc->dev;
> + u32 vblank, pipe = drm_crtc_index(crtc);
> + unsigned long flags;
> +
> + WARN(dev->max_vblank_count, "This function is only useful when a hw 
> counter is unavailable.");

It's useful on everything if you actually want to trust the
software counter to not be stale.

> +
> + spin_lock_irqsave(>vblank_time_lock, flags);
> + drm_update_vblank_count(dev, pipe, 0);
> +
> + vblank = dev->vblank[pipe].count;
> + *tv_ret = vblanktimestamp(dev, pipe, vblank);

Do we have a user in mind that would care about the timestamp?

> +
> + spin_unlock_irqrestore(>vblank_time_lock, flags);
> +
> + return vblank;
> +}
> +EXPORT_SYMBOL(drm_accurate_vblank_count_and_time);
> +
>  /*
>   * Disable vblank irq's on crtc, make sure that last vblank count
>   * of hardware and corresponding consistent software vblank counter
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 31483c2fef51..1df65922c7c6 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -995,6 +995,8 @@ extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
>  extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
>  extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
>  extern void drm_vblank_cleanup(struct drm_device *dev);
> +extern u32 drm_accurate_vblank_count_and_time(struct drm_crtc *crtc,
> +   struct timeval *tv_ret);
>  extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int 
> pipe);
>  
>  extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
> -- 
> 2.1.0
> 

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

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915: Avoid allocating a vmap arena for a single page

[Tvrtko Ursulin]

On 08/04/16 12:11, Chris Wilson wrote:

If we want a contiguous mapping of a single page sized object, we can
forgo using vmap() and just use a regular kmap(). Note that this is only
suitable if the desired pgprot_t is compatible.

v2: Use is_vmalloc_addr()

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_gem.c | 19 ++-
  1 file changed, 14 insertions(+), 5 deletions(-)


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko


diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fa810226bd8b..b37ffea8b458 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2233,7 +2233,10 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
*obj)
list_del(>global_list);

if (obj->mapping) {
-   vunmap(obj->mapping);
+   if (is_vmalloc_addr(obj->mapping))
+   vunmap(obj->mapping);
+   else
+   kunmap(kmap_to_page(obj->mapping));
obj->mapping = NULL;
}

@@ -2418,13 +2421,19 @@ void *i915_gem_object_pin_map(struct 
drm_i915_gem_object *obj)
i915_gem_object_pin_pages(obj);

if (obj->mapping == NULL) {
-   struct sg_page_iter sg_iter;
struct page **pages;
-   int n;

-   n = obj->base.size >> PAGE_SHIFT;
-   pages = drm_malloc_gfp(n, sizeof(*pages), GFP_TEMPORARY);
+   pages = NULL;
+   if (obj->base.size == PAGE_SIZE)
+   obj->mapping = kmap(sg_page(obj->pages->sgl));
+   else
+   pages = drm_malloc_gfp(obj->base.size >> PAGE_SHIFT,
+  sizeof(*pages),
+  GFP_TEMPORARY);
if (pages != NULL) {
+   struct sg_page_iter sg_iter;
+   int n;
+
n = 0;
for_each_sg_page(obj->pages->sgl, _iter,
 obj->pages->nents, 0)


___
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: Fix VLV/CHV unclaimed register errors

[Patchwork]

== Series Details ==

Series: drm/i915: Fix VLV/CHV unclaimed register errors
URL   : https://patchwork.freedesktop.org/series/5531/
State : failure

== Summary ==

Series 5531v1 drm/i915: Fix VLV/CHV unclaimed register errors
http://patchwork.freedesktop.org/api/1.0/series/5531/revisions/1/mbox/

Test gem_busy:
Subgroup basic-blt:
pass   -> INCOMPLETE (snb-dellxps)
Subgroup basic-render:
skip   -> PASS   (hsw-gt2)
Test gem_ctx_param_basic:
Subgroup invalid-ctx-get:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup non-root-set:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_exec_basic:
Subgroup gtt-bsd:
pass   -> SKIP   (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-small-copy-xy:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-write-no-prefault:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_storedw_loop:
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup no-handle:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-edid:
pass   -> SKIP   (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> SKIP   (hsw-brixbox)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-rte:
dmesg-warn -> PASS   (bsw-nuc-2)

bdw-ultratotal:202  pass:179  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:201  pass:152  dwarn:6   dfail:2   fail:0   skip:41 
byt-nuc  total:201  pass:163  dwarn:0   dfail:0   fail:0   skip:38 
hsw-brixbox  total:202  pass:177  dwarn:0   dfail:0   fail:0   skip:25 
hsw-gt2  total:202  pass:183  dwarn:0   dfail:0   fail:0   skip:19 
ilk-hp8440p  total:202  pass:134  dwarn:0   dfail:0   fail:0   skip:68 
ivb-t430stotal:202  pass:173  dwarn:0   dfail:0   fail:0   skip:29 
skl-i7k-2total:202  pass:177  dwarn:0   dfail:0   fail:0   skip:25 
skl-nuci5total:202  pass:191  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps  total:99   pass:78   dwarn:0   dfail:0   fail:0   skip:20 
snb-x220ttotal:202  pass:164  dwarn:0   dfail:0   fail:1   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_1862/

75635547cc623acbbe3941b93264e8cbb4686d29 drm-intel-nightly: 
2016y-04m-11d-11h-18m-04s UTC integration manifest
95404e98fda24cf0dfeabe00ee7804eea06d18d0 Revert "drm/i915: Limit the auto 
arming of mmio debugs on vlv/chv"
fc295dfee66f06591567d612d44dd2eb58850cc7 drm/i915: Move DPINVGTT setup to 
vlv_display_irq_reset()
35066da8bb1da5efe15530768c0b52eabec0c503 drm/i915: Move 
vlv_init_display_clock_gating() to the display power well
64ef8c05a4977c1213f4661ca550d598bca16729 drm/i915: Warn if irq_mask isn't ~0 
during vlv/cvh display irq postinstall
fd065544c0dd09a7bb0333b89970baeb0cf19094 drm/i915: Use GEN5_IRQ_INIT() in 
vlv_display_irq_postinstall()
c853feb33c049e8e68ec528c4d637d879cefb4bb drm/i915: Clear display interrupt 
before enabling when turning on the power well
87f3206fa3c5c221d0ae8663838626a8c7943c7d drm/i915: Move vlv/chv display irq 
code to a more logical place
1d4460e646432e31608f44579d015f0208b80657 drm/i915: Skip display irq setup if 
display irqs aren't flagged as enabled
a0d1632e07bd77ac39a6121c262d2a612d08df0e drm/i915: Fix up vlv/chv display irq 
setup
6ed27b693027247102533f20c7b00af2f4f0265f drm/i915: Remove "VLV magic" from irq 
setup

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

Re: [Intel-gfx] [PATCH v2 4/6] drm/i915/shrinker: Restrict vmap purge to objects with vmaps

[Tvrtko Ursulin]

On 08/04/16 12:11, Chris Wilson wrote:

When called because we have run out of vmap address space, we only need
to recover objects that have vmappings and not all.

v2: Start using is_vmalloc_addr()

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


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko



diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eda4218e2ede..4061a11e4234 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3338,6 +3338,7 @@ unsigned long i915_gem_shrink(struct drm_i915_private 
*dev_priv,
  #define I915_SHRINK_UNBOUND 0x2
  #define I915_SHRINK_BOUND 0x4
  #define I915_SHRINK_ACTIVE 0x8
+#define I915_SHRINK_VMAPS 0x10
  unsigned long i915_gem_shrink_all(struct drm_i915_private *dev_priv);
  void i915_gem_shrinker_init(struct drm_i915_private *dev_priv);
  void i915_gem_shrinker_cleanup(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 39943793edcc..d46388f25e04 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -167,6 +167,10 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
obj->madv != I915_MADV_DONTNEED)
continue;

+   if (flags & I915_SHRINK_VMAPS &&
+   !is_vmalloc_addr(obj->mapping))
+   continue;
+
if ((flags & I915_SHRINK_ACTIVE) == 0 && obj->active)
continue;

@@ -388,7 +392,11 @@ i915_gem_shrinker_vmap(struct notifier_block *nb, unsigned 
long event, void *ptr
if (!i915_gem_shrinker_lock_uninterruptible(dev_priv, , 5000))
return NOTIFY_DONE;

-   freed_pages = i915_gem_shrink_all(dev_priv);
+   freed_pages = i915_gem_shrink(dev_priv, -1UL,
+ I915_SHRINK_BOUND |
+ I915_SHRINK_UNBOUND |
+ I915_SHRINK_ACTIVE |
+ I915_SHRINK_VMAPS);

i915_gem_shrinker_unlock_uninterruptible(dev_priv, );



___
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: Refactor duplicate object vmap functions

[Tvrtko Ursulin]

On 08/04/16 12:11, Chris Wilson wrote:

We now have two implementations for vmapping a whole object, one for
dma-buf and one for the ringbuffer. If we couple the mapping into the
obj->pages lifetime, then we can reuse an obj->mapping for both and at
the same time couple it into the shrinker. There is a third vmapping
routine in the cmdparser that maps only a range within the object, for
the time being that is left alone, but will eventually use these routines
in order to cache the mapping between invocations.

v2: Mark the failable kmalloc() as __GFP_NOWARN (vsyrjala)
v3: Call unpin_vmap from the right dmabuf unmapper

v4: Rename vmap to map as we don't wish to imply the type of mapping
involved, just that it contiguously maps the object into kernel space.
Add kerneldoc and lockdep annotations

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_drv.h | 37 ++---
  drivers/gpu/drm/i915/i915_gem.c | 44 +
  drivers/gpu/drm/i915/i915_gem_dmabuf.c  | 49 -
  drivers/gpu/drm/i915/intel_ringbuffer.c | 26 ++---
  4 files changed, 84 insertions(+), 72 deletions(-)


Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko



diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a93e5dd4fa9a..eda4218e2ede 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2169,10 +2169,7 @@ struct drm_i915_gem_object {
struct scatterlist *sg;
int last;
} get_page;
-
-   /* prime dma-buf support */
-   void *dma_buf_vmapping;
-   int vmapping_count;
+   void *mapping;

/** Breadcrumb of last rendering to the buffer.
 * There can only be one writer, but we allow for multiple readers.
@@ -2988,12 +2985,44 @@ static inline void i915_gem_object_pin_pages(struct 
drm_i915_gem_object *obj)
BUG_ON(obj->pages == NULL);
obj->pages_pin_count++;
  }
+
  static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object 
*obj)
  {
BUG_ON(obj->pages_pin_count == 0);
obj->pages_pin_count--;
  }

+/**
+ * i915_gem_object_pin_map - return a contiguous mapping of the entire object
+ * @obj - the object to map into kernel address space
+ *
+ * Calls i915_gem_object_pin_pages() to prevent reaping of the object's
+ * pages and then returns a contiguous mapping of the backing storage into
+ * the kernel address space.
+ *
+ * The caller must hold the struct_mutex.
+ *
+ * Returns the pointer through which to access the backing storage.
+ */
+void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj);
+
+/**
+ * i915_gem_object_unpin_map - releases an earlier mapping
+ * @obj - the object to unmap
+ *
+ * After pinning the object and mapping its pages, once you are finished
+ * with your access, call i915_gem_object_unpin_map() to release the pin
+ * upon the mapping. Once the pin count reaches zero, that mapping may be
+ * removed.
+ *
+ * The caller must hold the struct_mutex.
+ */
+static inline void i915_gem_object_unpin_map(struct drm_i915_gem_object *obj)
+{
+   lockdep_assert_held(>base.dev->struct_mutex);
+   i915_gem_object_unpin_pages(obj);
+}
+
  int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
  int i915_gem_object_sync(struct drm_i915_gem_object *obj,
 struct intel_engine_cs *to,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5a65a7663b88..fcbd47d36dcf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2232,6 +2232,11 @@ i915_gem_object_put_pages(struct drm_i915_gem_object 
*obj)
 * lists early. */
list_del(>global_list);

+   if (obj->mapping) {
+   vunmap(obj->mapping);
+   obj->mapping = NULL;
+   }
+
ops->put_pages(obj);
obj->pages = NULL;

@@ -2400,6 +2405,45 @@ i915_gem_object_get_pages(struct drm_i915_gem_object 
*obj)
return 0;
  }

+void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj)
+{
+   int ret;
+
+   lockdep_assert_held(>base.dev->struct_mutex);
+
+   ret = i915_gem_object_get_pages(obj);
+   if (ret)
+   return ERR_PTR(ret);
+
+   i915_gem_object_pin_pages(obj);
+
+   if (obj->mapping == NULL) {
+   struct sg_page_iter sg_iter;
+   struct page **pages;
+   int n;
+
+   n = obj->base.size >> PAGE_SHIFT;
+   pages = kmalloc(n*sizeof(*pages), GFP_TEMPORARY | __GFP_NOWARN);
+   if (pages == NULL)
+   pages = drm_malloc_ab(n, sizeof(*pages));
+   if (pages != NULL) {
+   n = 0;
+   

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Late request cancellations are harmful

[Chris Wilson]

On Mon, Apr 11, 2016 at 02:50:17PM +0100, Tvrtko Ursulin wrote:
> 
> On 09/04/16 10:27, Chris Wilson wrote:
> >Conceptually, each request is a record of a hardware transaction - we
> >build up a list of pending commands and then either commit them to
> >hardware, or cancel them. However, whilst building up the list of
> >pending commands, we may modify state outside of the request and make
> >references to the pending request. If we do so and then cancel that
> >request, external objects then point to the deleted request leading to
> >both graphical and memory corruption.
> >
> >The easiest example is to consider object/VMA tracking. When we mark an
> >object as active in a request, we store a pointer to this, the most
> >recent request, in the object. Then we want to free that object, we wait
> >for the most recent request to be idle before proceeding (otherwise the
> >hardware will write to pages now owned by the system, or we will attempt
> >to read from those pages before the hardware is finished writing). If
> >the request was cancelled instead, that wait completes immediately. As a
> >result, all requests must be committed and not cancelled if the external
> >state is unknown.
> 
> This was a bit hard to figure out.
> 
> So we cannot unwind because once we set last_read_req we lose the
> data on what was the previous one, before this transaction started?
> 
> Intuitively I don't like the idea of sending unfinished stuff to the
> GPU, when it failed at some random point in ring buffer preparation.

Yes, but it is not unfinished though. The mm-switch is made and
flagged as completed, etc. The request does contain instructions for the
state changes it has made so far.
 
> So I am struggling with reviewing this as I have in the previous round.
> 
> >All that remains of i915_gem_request_cancel() users are just a couple of
> >extremely unlikely allocation failures, so remove the API entirely.
> 
> This parts feels extra weird because in the non-execbuf cases we
> actually can cancel the transaction without any issues, correct?

Nope. Same problem arises in that they do not know what happens
underneath calls to e.g. object_sync. Before cancellation you have to
inspect every path now and in the future to be sure that no state was
modified inside the request.
 
> Would middle-ground be to keep the cancellations for in-kernel
> submits, and for execbuf rewind the ringbuf so only request
> post-amble is sent to the GPU?

The only place that knows whether an external observer is the request
code. I am thinking about doing the cancellation there, I just need to
check that the lockless idling will be ok with that.

> >@@ -3410,12 +3404,9 @@ int i915_gpu_idle(struct drm_device *dev)
> > return PTR_ERR(req);
> >
> > ret = i915_switch_context(req);
> >-if (ret) {
> >-i915_gem_request_cancel(req);
> >-return ret;
> >-}
> >-
> > i915_add_request_no_flush(req);
> >+if (ret)
> >+return ret;
> 
> Looks like with this it could execute the context switch on the GPU
> but not update the engine->last_context in do_switch().

Hmm, that problem is present in the current code - requests are not
unwound, just deleted. We need to rearrange switch_context after the
mi_set_context() to ensure that on the subsequent call, the context is
reloaded.
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

[Patchwork]

== Series Details ==

Series: Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"
URL   : https://patchwork.freedesktop.org/series/5528/
State : failure

== Summary ==

Series 5528v1 Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"
http://patchwork.freedesktop.org/api/1.0/series/5528/revisions/1/mbox/

Test gem_basic:
Subgroup create-close:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_busy:
Subgroup basic-render:
skip   -> PASS   (hsw-gt2)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test gem_ctx_create:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_exec:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup basic-default:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup invalid-ctx-get:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup invalid-ctx-set:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup invalid-size-set:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup non-root-set:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup non-root-set-no-zeromap:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
Subgroup readonly-blt:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_nop:
Subgroup basic:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)
Test gem_flink_basic:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_mmap:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-copy:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-read:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-read-no-prefault:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-short:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-write-gtt-no-prefault:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_pread:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Test gem_storedw_loop:
Subgroup basic-vebox:
pass   -> SKIP   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-each:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-bad-modifier:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup addfb25-yf-tiled:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bad-pitch-128:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bad-pitch-256:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-y-tiled:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bo-too-small:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup too-wide:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> INCOMPLETE (bsw-nuc-2)
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
Subgroup basic-plain-flip:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (byt-nuc)
Test pm_rps:
Subgroup basic-api:
pass   -> DMESG-WARN (bsw-nuc-2)
Test prime_self_import:
Subgroup basic-llseek-bad:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-llseek-size:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-ultratotal:202  pass:179  dwarn:0   dfail:0   fail:0   skip:23 
bsw-nuc-2total:111  pass:50   dwarn:30  dfail:4   fail:0   skip:26 
byt-nuc  total:202  pass:163  dwarn:1   dfail:0   fail:0   skip:38 
hsw-brixbox  total:202  pass:178  dwarn:0   dfail:0   fail:0   skip:24 
hsw-gt2  total:202  pass:183  dwarn:0   dfail:0   fail:0   skip:19 
ilk-hp8440p  total:202  pass:134  dwarn:0   dfail:0   fail:0   skip:68 

[Intel-gfx] [PATCH 08/10] drm/i915: Move vlv_init_display_clock_gating() to the display power well

[ville . syrjala]

From: Ville Syrjälä 

The registers frobbed by vlv_init_display_clock_gating() libve inside
the disp2d power well, so frobbing them while the power well is down
results in unclaimed register access warning (and of course the values
won't stick). Let's do this setup after we know the power well is
enabled.

It's also worth noting that DSPCLK_GATE_D and CBR1_VLV lose their state
when the power well goes down, but fortunately the values we've been
writing are actually the reset defaults.

MI_ARB_VLV actually retains its value even if the power well was turned
off, we just can't access it while the power well is down.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 15 ---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 13 +
 2 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 43b24a1f5ee6..c80d044fe082 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6882,23 +6882,10 @@ static void ivybridge_init_clock_gating(struct 
drm_device *dev)
gen6_check_mch_setup(dev);
 }
 
-static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
-{
-   I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
-
-   /*
-* Disable trickle feed and enable pnd deadline calculation
-*/
-   I915_WRITE(MI_ARB_VLV, MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE);
-   I915_WRITE(CBR1_VLV, 0);
-}
-
 static void valleyview_init_clock_gating(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   vlv_init_display_clock_gating(dev_priv);
-
/* WaDisableEarlyCull:vlv */
I915_WRITE(_3D_CHICKEN3,
   _MASKED_BIT_ENABLE(_3D_CHICKEN_SF_DISABLE_OBJEND_CULL));
@@ -6981,8 +6968,6 @@ static void cherryview_init_clock_gating(struct 
drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   vlv_init_display_clock_gating(dev_priv);
-
/* WaVSRefCountFullforceMissDisable:chv */
/* WaDSRefCountFullforceMissDisable:chv */
I915_WRITE(GEN7_FF_THREAD_MODE,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 80e8bd4b43b5..8f9797f17991 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -900,6 +900,17 @@ static bool vlv_power_well_enabled(struct drm_i915_private 
*dev_priv,
return enabled;
 }
 
+static void vlv_init_display_clock_gating(struct drm_i915_private *dev_priv)
+{
+   I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
+
+   /*
+* Disable trickle feed and enable pnd deadline calculation
+*/
+   I915_WRITE(MI_ARB_VLV, MI_ARB_DISPLAY_TRICKLE_FEED_DISABLE);
+   I915_WRITE(CBR1_VLV, 0);
+}
+
 static void vlv_display_power_well_init(struct drm_i915_private *dev_priv)
 {
enum pipe pipe;
@@ -922,6 +933,8 @@ static void vlv_display_power_well_init(struct 
drm_i915_private *dev_priv)
I915_WRITE(DPLL(pipe), val);
}
 
+   vlv_init_display_clock_gating(dev_priv);
+
spin_lock_irq(_priv->irq_lock);
valleyview_enable_display_irqs(dev_priv);
spin_unlock_irq(_priv->irq_lock);
-- 
2.7.4

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

[Intel-gfx] [PATCH 00/10] drm/i915: Fix VLV/CHV unclaimed register errors

[ville . syrjala]

From: Ville Syrjälä 

There were two main causes for the VLV/CHV unclaimed register errors during
runtime PM transitons: dipslay irq setup and vlv_init_display_clock_gating().
This series reorganizes those things so that we only do them when the
disp2d power well is actually enabled.

Ville Syrjälä (10):
  drm/i915: Remove "VLV magic" from irq setup
  drm/i915: Fix up vlv/chv display irq setup
  drm/i915: Skip display irq setup if display irqs aren't flagged as
enabled
  drm/i915: Move vlv/chv display irq code to a more logical place
  drm/i915: Clear display interrupt before enabling when turning on the
power well
  drm/i915: Use GEN5_IRQ_INIT() in vlv_display_irq_postinstall()
  drm/i915: Warn if irq_mask isn't ~0 during vlv/cvh display irq
postinstall
  drm/i915: Move vlv_init_display_clock_gating() to the display power
well
  drm/i915: Move DPINVGTT setup to vlv_display_irq_reset()
  Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

 drivers/gpu/drm/i915/i915_irq.c | 217 +++-
 drivers/gpu/drm/i915/intel_pm.c |  15 ---
 drivers/gpu/drm/i915/intel_runtime_pm.c |  13 ++
 drivers/gpu/drm/i915/intel_uncore.c |   9 --
 4 files changed, 89 insertions(+), 165 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH 09/10] drm/i915: Move DPINVGTT setup to vlv_display_irq_reset()

[ville . syrjala]

From: Ville Syrjälä 

DPINVGTT lives inside the disp2d power well so we can't frob it unless
we know the power well is active. Let's this stuff into
vlv_display_irq_reset() which is only called at the right times so that
we don't get unclaimed register access errors.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 872f93dc68ff..d60c0e53f929 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3289,6 +3289,11 @@ static void vlv_display_irq_reset(struct 
drm_i915_private *dev_priv)
 {
enum pipe pipe;
 
+   if (IS_CHERRYVIEW(dev_priv))
+   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
+   else
+   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
+
i915_hotplug_interrupt_update_locked(dev_priv, 0x, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
 
@@ -3349,8 +3354,6 @@ static void valleyview_irq_preinstall(struct drm_device 
*dev)
 
gen5_gt_irq_reset(dev);
 
-   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
-
spin_lock_irq(_priv->irq_lock);
if (dev_priv->display_irqs_enabled)
vlv_display_irq_reset(dev_priv);
@@ -3427,8 +3430,6 @@ static void cherryview_irq_preinstall(struct drm_device 
*dev)
 
GEN5_IRQ_RESET(GEN8_PCU_);
 
-   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
-
spin_lock_irq(_priv->irq_lock);
if (dev_priv->display_irqs_enabled)
vlv_display_irq_reset(dev_priv);
@@ -3714,12 +3715,6 @@ static int valleyview_irq_postinstall(struct drm_device 
*dev)
 
gen5_gt_irq_postinstall(dev);
 
-   /* ack & enable invalid PTE error interrupts */
-#if 0 /* FIXME: add support to irq handler for checking these bits */
-   I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
-   I915_WRITE(DPINVGTT, DPINVGTT_EN_MASK);
-#endif
-
spin_lock_irq(_priv->irq_lock);
if (dev_priv->display_irqs_enabled)
vlv_display_irq_postinstall(dev_priv);
-- 
2.7.4

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

[Intel-gfx] [PATCH 05/10] drm/i915: Clear display interrupt before enabling when turning on the power well

[ville . syrjala]

From: Ville Syrjälä 

For a bit of extra paranoia make sure the display irqs are all cleared
before we enabled them when turning on the power well. This should
really be the case already since the power well was off which resets
everything.

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

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c119610e2d57..678c6b86862e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3306,13 +3306,6 @@ static void vlv_display_irq_postinstall(struct 
drm_i915_private *dev_priv)
u32 iir_mask;
enum pipe pipe;
 
-   pipestat_mask = PIPESTAT_INT_STATUS_MASK |
-   PIPE_FIFO_UNDERRUN_STATUS;
-
-   for_each_pipe(dev_priv, pipe)
-   I915_WRITE(PIPESTAT(pipe), pipestat_mask);
-   POSTING_READ(PIPESTAT(PIPE_A));
-
pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
PIPE_CRC_DONE_INTERRUPT_STATUS;
 
@@ -3696,8 +3689,10 @@ void valleyview_enable_display_irqs(struct 
drm_i915_private *dev_priv)
 
dev_priv->display_irqs_enabled = true;
 
-   if (intel_irqs_enabled(dev_priv))
+   if (intel_irqs_enabled(dev_priv)) {
+   vlv_display_irq_reset(dev_priv);
vlv_display_irq_postinstall(dev_priv);
+   }
 }
 
 void valleyview_disable_display_irqs(struct drm_i915_private *dev_priv)
-- 
2.7.4

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

[Intel-gfx] [PATCH 10/10] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

[ville . syrjala]

From: Ville Syrjälä 

Enable the unclaimd register detection stuff on vlv/chv since we've now
fixed the known problems during suspend.

This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_uncore.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index ac2ac07b505b..2f7fb7d169b8 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -633,15 +633,6 @@ __unclaimed_reg_debug(struct drm_i915_private *dev_priv,
  const bool read,
  const bool before)
 {
-   /* XXX. We limit the auto arming traces for mmio
-* debugs on these platforms. There are just too many
-* revealed by these and CI/Bat suffers from the noise.
-* Please fix and then re-enable the automatic traces.
-*/
-   if (i915.mmio_debug < 2 &&
-   (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
-   return;
-
if (WARN(check_for_unclaimed_mmio(dev_priv),
 "Unclaimed register detected %s %s register 0x%x\n",
 before ? "before" : "after",
-- 
2.7.4

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

[Intel-gfx] [PATCH 07/10] drm/i915: Warn if irq_mask isn't ~0 during vlv/cvh display irq postinstall

[ville . syrjala]

From: Ville Syrjälä 

We expect vlv_display_irq_reset() to have been called prior to
vlv_display_irq_postinstall() so let's WARN if that isn't the case.

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

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f6815e47d8de..872f93dc68ff 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3318,6 +3318,9 @@ static void vlv_display_irq_postinstall(struct 
drm_i915_private *dev_priv)
I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
if (IS_CHERRYVIEW(dev_priv))
enable_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
+
+   WARN_ON(dev_priv->irq_mask != ~0);
+
dev_priv->irq_mask = ~enable_mask;
 
GEN5_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
-- 
2.7.4

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

[Intel-gfx] [PATCH 06/10] drm/i915: Use GEN5_IRQ_INIT() in vlv_display_irq_postinstall()

[ville . syrjala]

From: Ville Syrjälä 

Replace the hand rolled IMR/IER setup in vlv_display_irq_postinstall()
with GEN5_IRQ_INIT(). Also rename the iir_mask to enable_mask to avoid
consusion since we no longer deal with IIR here.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 678c6b86862e..f6815e47d8de 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3303,7 +3303,7 @@ static void vlv_display_irq_reset(struct drm_i915_private 
*dev_priv)
 static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
 {
u32 pipestat_mask;
-   u32 iir_mask;
+   u32 enable_mask;
enum pipe pipe;
 
pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
@@ -3313,18 +3313,14 @@ static void vlv_display_irq_postinstall(struct 
drm_i915_private *dev_priv)
for_each_pipe(dev_priv, pipe)
i915_enable_pipestat(dev_priv, pipe, pipestat_mask);
 
-   iir_mask = I915_DISPLAY_PORT_INTERRUPT |
-  I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
-  I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
+   enable_mask = I915_DISPLAY_PORT_INTERRUPT |
+   I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
+   I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
if (IS_CHERRYVIEW(dev_priv))
-   iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
-   dev_priv->irq_mask &= ~iir_mask;
-
-   I915_WRITE(VLV_IIR, iir_mask);
-   I915_WRITE(VLV_IIR, iir_mask);
-   I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
-   I915_WRITE(VLV_IMR, dev_priv->irq_mask);
-   POSTING_READ(VLV_IMR);
+   enable_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
+   dev_priv->irq_mask = ~enable_mask;
+
+   GEN5_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
 }
 
 /* drm_dma.h hooks
-- 
2.7.4

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

[Intel-gfx] [PATCH 04/10] drm/i915: Move vlv/chv display irq code to a more logical place

[ville . syrjala]

From: Ville Syrjälä 

Reshuffle the code a bit to move the vlv/chv display irq functions away
from the main irq hooks, next to the other sub (de,gt,etc.) hooks.

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

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5c6511a5a74b..c119610e2d57 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3285,6 +3285,55 @@ static void gen5_gt_irq_reset(struct drm_device *dev)
GEN5_IRQ_RESET(GEN6_PM);
 }
 
+static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
+{
+   enum pipe pipe;
+
+   i915_hotplug_interrupt_update_locked(dev_priv, 0x, 0);
+   I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
+
+   for_each_pipe(dev_priv, pipe)
+   I915_WRITE(PIPESTAT(pipe), 0x);
+
+   GEN5_IRQ_RESET(VLV_);
+
+   dev_priv->irq_mask = ~0;
+}
+
+static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
+{
+   u32 pipestat_mask;
+   u32 iir_mask;
+   enum pipe pipe;
+
+   pipestat_mask = PIPESTAT_INT_STATUS_MASK |
+   PIPE_FIFO_UNDERRUN_STATUS;
+
+   for_each_pipe(dev_priv, pipe)
+   I915_WRITE(PIPESTAT(pipe), pipestat_mask);
+   POSTING_READ(PIPESTAT(PIPE_A));
+
+   pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
+   PIPE_CRC_DONE_INTERRUPT_STATUS;
+
+   i915_enable_pipestat(dev_priv, PIPE_A, PIPE_GMBUS_INTERRUPT_STATUS);
+   for_each_pipe(dev_priv, pipe)
+   i915_enable_pipestat(dev_priv, pipe, pipestat_mask);
+
+   iir_mask = I915_DISPLAY_PORT_INTERRUPT |
+  I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
+  I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
+   if (IS_CHERRYVIEW(dev_priv))
+   iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
+   dev_priv->irq_mask &= ~iir_mask;
+
+   I915_WRITE(VLV_IIR, iir_mask);
+   I915_WRITE(VLV_IIR, iir_mask);
+   I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
+   I915_WRITE(VLV_IMR, dev_priv->irq_mask);
+   POSTING_READ(VLV_IMR);
+}
+
 /* drm_dma.h hooks
 */
 static void ironlake_irq_reset(struct drm_device *dev)
@@ -3302,21 +3351,6 @@ static void ironlake_irq_reset(struct drm_device *dev)
ibx_irq_reset(dev);
 }
 
-static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
-{
-   enum pipe pipe;
-
-   i915_hotplug_interrupt_update_locked(dev_priv, 0x, 0);
-   I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
-
-   for_each_pipe(dev_priv, pipe)
-   I915_WRITE(PIPESTAT(pipe), 0x);
-
-   GEN5_IRQ_RESET(VLV_);
-
-   dev_priv->irq_mask = ~0;
-}
-
 static void valleyview_irq_preinstall(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3653,40 +3687,6 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
return 0;
 }
 
-static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
-{
-   u32 pipestat_mask;
-   u32 iir_mask;
-   enum pipe pipe;
-
-   pipestat_mask = PIPESTAT_INT_STATUS_MASK |
-   PIPE_FIFO_UNDERRUN_STATUS;
-
-   for_each_pipe(dev_priv, pipe)
-   I915_WRITE(PIPESTAT(pipe), pipestat_mask);
-   POSTING_READ(PIPESTAT(PIPE_A));
-
-   pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
-   PIPE_CRC_DONE_INTERRUPT_STATUS;
-
-   i915_enable_pipestat(dev_priv, PIPE_A, PIPE_GMBUS_INTERRUPT_STATUS);
-   for_each_pipe(dev_priv, pipe)
- i915_enable_pipestat(dev_priv, pipe, pipestat_mask);
-
-   iir_mask = I915_DISPLAY_PORT_INTERRUPT |
-  I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
-  I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
-   if (IS_CHERRYVIEW(dev_priv))
-   iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
-   dev_priv->irq_mask &= ~iir_mask;
-
-   I915_WRITE(VLV_IIR, iir_mask);
-   I915_WRITE(VLV_IIR, iir_mask);
-   I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
-   I915_WRITE(VLV_IMR, dev_priv->irq_mask);
-   POSTING_READ(VLV_IMR);
-}
-
 void valleyview_enable_display_irqs(struct drm_i915_private *dev_priv)
 {
assert_spin_locked(_priv->irq_lock);
-- 
2.7.4

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

[Intel-gfx] [PATCH 03/10] drm/i915: Skip display irq setup if display irqs aren't flagged as enabled

[ville . syrjala]

From: Ville Syrjälä 

During runtime PM we'll be reinitializing interrupt support from the
ground up. However since the display power well will be off at that
time, well end up with a ton of unclaimed register accesses from the
display irq setup. Since we turned off the power well already before
runtime suspend, we've flagged display irqs as disabled during runtime
PM transitions. So we can just check that flag to see if we should do
skip display irqs during irq setup.

During driver load display irqs will be flagged as enabled since we've
turned on the power well already, however the power well code will have
skipped the display irq setup since irq support as a whole wasn't yet
enabled when the power well was enabled. So we'll want to do the display
irq setup in that case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a1239fedc086..5c6511a5a74b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3326,7 +3326,8 @@ static void valleyview_irq_preinstall(struct drm_device 
*dev)
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
 
spin_lock_irq(_priv->irq_lock);
-   vlv_display_irq_reset(dev_priv);
+   if (dev_priv->display_irqs_enabled)
+   vlv_display_irq_reset(dev_priv);
spin_unlock_irq(_priv->irq_lock);
 }
 
@@ -3403,7 +3404,8 @@ static void cherryview_irq_preinstall(struct drm_device 
*dev)
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
 
spin_lock_irq(_priv->irq_lock);
-   vlv_display_irq_reset(dev_priv);
+   if (dev_priv->display_irqs_enabled)
+   vlv_display_irq_reset(dev_priv);
spin_unlock_irq(_priv->irq_lock);
 }
 
@@ -3725,7 +3727,8 @@ static int valleyview_irq_postinstall(struct drm_device 
*dev)
 #endif
 
spin_lock_irq(_priv->irq_lock);
-   vlv_display_irq_postinstall(dev_priv);
+   if (dev_priv->display_irqs_enabled)
+   vlv_display_irq_postinstall(dev_priv);
spin_unlock_irq(_priv->irq_lock);
 
I915_WRITE(VLV_MASTER_IER, MASTER_INTERRUPT_ENABLE);
@@ -3831,7 +3834,8 @@ static int cherryview_irq_postinstall(struct drm_device 
*dev)
gen8_gt_irq_postinstall(dev_priv);
 
spin_lock_irq(_priv->irq_lock);
-   vlv_display_irq_postinstall(dev_priv);
+   if (dev_priv->display_irqs_enabled)
+   vlv_display_irq_postinstall(dev_priv);
spin_unlock_irq(_priv->irq_lock);
 
I915_WRITE(GEN8_MASTER_IRQ, MASTER_INTERRUPT_ENABLE);
@@ -3864,7 +3868,8 @@ static void valleyview_irq_uninstall(struct drm_device 
*dev)
I915_WRITE(HWSTAM, 0x);
 
spin_lock_irq(_priv->irq_lock);
-   vlv_display_irq_reset(dev_priv);
+   if (dev_priv->display_irqs_enabled)
+   vlv_display_irq_reset(dev_priv);
spin_unlock_irq(_priv->irq_lock);
 }
 
@@ -3883,7 +3888,8 @@ static void cherryview_irq_uninstall(struct drm_device 
*dev)
GEN5_IRQ_RESET(GEN8_PCU_);
 
spin_lock_irq(_priv->irq_lock);
-   vlv_display_irq_reset(dev_priv);
+   if (dev_priv->display_irqs_enabled)
+   vlv_display_irq_reset(dev_priv);
spin_unlock_irq(_priv->irq_lock);
 }
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 02/10] drm/i915: Fix up vlv/chv display irq setup

[ville . syrjala]

From: Ville Syrjälä 

The vlv/chv display irq setup was a bit of mess after I ran out of steam
when working on it last. Fix it up so that we just have a _reset() and
_postinstall() hooks for the display irqs, and use those consistently.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_irq.c | 102 ++--
 1 file changed, 24 insertions(+), 78 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1d21ebfffd4d..a1239fedc086 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3306,13 +3306,15 @@ static void vlv_display_irq_reset(struct 
drm_i915_private *dev_priv)
 {
enum pipe pipe;
 
-   i915_hotplug_interrupt_update(dev_priv, 0x, 0);
+   i915_hotplug_interrupt_update_locked(dev_priv, 0x, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
 
for_each_pipe(dev_priv, pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
 
GEN5_IRQ_RESET(VLV_);
+
+   dev_priv->irq_mask = ~0;
 }
 
 static void valleyview_irq_preinstall(struct drm_device *dev)
@@ -3323,7 +3325,9 @@ static void valleyview_irq_preinstall(struct drm_device 
*dev)
 
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
 
+   spin_lock_irq(_priv->irq_lock);
vlv_display_irq_reset(dev_priv);
+   spin_unlock_irq(_priv->irq_lock);
 }
 
 static void gen8_gt_irq_reset(struct drm_i915_private *dev_priv)
@@ -3398,7 +3402,9 @@ static void cherryview_irq_preinstall(struct drm_device 
*dev)
 
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK_CHV);
 
+   spin_lock_irq(_priv->irq_lock);
vlv_display_irq_reset(dev_priv);
+   spin_unlock_irq(_priv->irq_lock);
 }
 
 static u32 intel_hpd_enabled_irqs(struct drm_device *dev,
@@ -3645,7 +3651,7 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
return 0;
 }
 
-static void valleyview_display_irqs_install(struct drm_i915_private *dev_priv)
+static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
 {
u32 pipestat_mask;
u32 iir_mask;
@@ -3679,40 +3685,6 @@ static void valleyview_display_irqs_install(struct 
drm_i915_private *dev_priv)
POSTING_READ(VLV_IMR);
 }
 
-static void valleyview_display_irqs_uninstall(struct drm_i915_private 
*dev_priv)
-{
-   u32 pipestat_mask;
-   u32 iir_mask;
-   enum pipe pipe;
-
-   iir_mask = I915_DISPLAY_PORT_INTERRUPT |
-  I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
-  I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
-   if (IS_CHERRYVIEW(dev_priv))
-   iir_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
-
-   dev_priv->irq_mask |= iir_mask;
-   I915_WRITE(VLV_IMR, dev_priv->irq_mask);
-   I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
-   I915_WRITE(VLV_IIR, iir_mask);
-   I915_WRITE(VLV_IIR, iir_mask);
-   POSTING_READ(VLV_IIR);
-
-   pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
-   PIPE_CRC_DONE_INTERRUPT_STATUS;
-
-   i915_disable_pipestat(dev_priv, PIPE_A, PIPE_GMBUS_INTERRUPT_STATUS);
-   for_each_pipe(dev_priv, pipe)
-   i915_disable_pipestat(dev_priv, pipe, pipestat_mask);
-
-   pipestat_mask = PIPESTAT_INT_STATUS_MASK |
-   PIPE_FIFO_UNDERRUN_STATUS;
-
-   for_each_pipe(dev_priv, pipe)
-   I915_WRITE(PIPESTAT(pipe), pipestat_mask);
-   POSTING_READ(PIPESTAT(PIPE_A));
-}
-
 void valleyview_enable_display_irqs(struct drm_i915_private *dev_priv)
 {
assert_spin_locked(_priv->irq_lock);
@@ -3723,7 +3695,7 @@ void valleyview_enable_display_irqs(struct 
drm_i915_private *dev_priv)
dev_priv->display_irqs_enabled = true;
 
if (intel_irqs_enabled(dev_priv))
-   valleyview_display_irqs_install(dev_priv);
+   vlv_display_irq_postinstall(dev_priv);
 }
 
 void valleyview_disable_display_irqs(struct drm_i915_private *dev_priv)
@@ -3736,36 +3708,14 @@ void valleyview_disable_display_irqs(struct 
drm_i915_private *dev_priv)
dev_priv->display_irqs_enabled = false;
 
if (intel_irqs_enabled(dev_priv))
-   valleyview_display_irqs_uninstall(dev_priv);
+   vlv_display_irq_reset(dev_priv);
 }
 
-static void vlv_display_irq_postinstall(struct drm_i915_private *dev_priv)
-{
-   dev_priv->irq_mask = ~0;
-
-   i915_hotplug_interrupt_update(dev_priv, 0x, 0);
-   POSTING_READ(PORT_HOTPLUG_EN);
-
-   I915_WRITE(VLV_IIR, 0x);
-   I915_WRITE(VLV_IIR, 0x);
-   I915_WRITE(VLV_IER, ~dev_priv->irq_mask);
-   I915_WRITE(VLV_IMR, dev_priv->irq_mask);
-   POSTING_READ(VLV_IMR);
-
-   /* Interrupt setup is already guaranteed to be single-threaded, this is
-* just to make the assert_spin_locked check happy. */
-   spin_lock_irq(_priv->irq_lock);
-   if 

[Intel-gfx] [PATCH 01/10] drm/i915: Remove "VLV magic" from irq setup

[ville . syrjala]

From: Ville Syrjälä 

No clue what this is supposed to achieve. I think it's been there since
the very beginning, so presumably some kind of kludge for very early
silicon. Let's just throw it out.

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

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 679f08c944ef..1d21ebfffd4d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3319,12 +3319,6 @@ static void valleyview_irq_preinstall(struct drm_device 
*dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   /* VLV magic */
-   I915_WRITE(VLV_IMR, 0);
-   I915_WRITE(RING_IMR(RENDER_RING_BASE), 0);
-   I915_WRITE(RING_IMR(GEN6_BSD_RING_BASE), 0);
-   I915_WRITE(RING_IMR(BLT_RING_BASE), 0);
-
gen5_gt_irq_reset(dev);
 
I915_WRITE(DPINVGTT, DPINVGTT_STATUS_MASK);
-- 
2.7.4

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

Re: [Intel-gfx] [for-CI] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

[Ville Syrjälä]

On Mon, Apr 11, 2016 at 02:37:09PM +0100, Chris Wilson wrote:
> On Mon, Apr 11, 2016 at 04:31:28PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 11, 2016 at 02:21:01PM +0100, Chris Wilson wrote:
> > > This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
> > 
> > Not quite yet. I have patches pretty much line up to fix the resulting
> > spew. Just got a bit sidetracked by the CHV irq problems.
> 
> Aye, this was just probing CI to see if we can get an explanation for
> some [drm:cherryview_enable_rps] GT fifo had a previous error 108
> in recent runs.

Those bits aren't actually errors. They're just FIFO free space
counters.

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Late request cancellations are harmful

[Tvrtko Ursulin]

On 09/04/16 10:27, Chris Wilson wrote:

Conceptually, each request is a record of a hardware transaction - we
build up a list of pending commands and then either commit them to
hardware, or cancel them. However, whilst building up the list of
pending commands, we may modify state outside of the request and make
references to the pending request. If we do so and then cancel that
request, external objects then point to the deleted request leading to
both graphical and memory corruption.

The easiest example is to consider object/VMA tracking. When we mark an
object as active in a request, we store a pointer to this, the most
recent request, in the object. Then we want to free that object, we wait
for the most recent request to be idle before proceeding (otherwise the
hardware will write to pages now owned by the system, or we will attempt
to read from those pages before the hardware is finished writing). If
the request was cancelled instead, that wait completes immediately. As a
result, all requests must be committed and not cancelled if the external
state is unknown.


This was a bit hard to figure out.

So we cannot unwind because once we set last_read_req we lose the data 
on what was the previous one, before this transaction started?


Intuitively I don't like the idea of sending unfinished stuff to the
GPU, when it failed at some random point in ring buffer preparation.

So I am struggling with reviewing this as I have in the previous round.


All that remains of i915_gem_request_cancel() users are just a couple of
extremely unlikely allocation failures, so remove the API entirely.


This parts feels extra weird because in the non-execbuf cases we 
actually can cancel the transaction without any issues, correct?


Would middle-ground be to keep the cancellations for in-kernel submits, 
and for execbuf rewind the ringbuf so only request post-amble is sent to 
the GPU?



A consequence of committing all incomplete requests is that we generate
excess breadcrumbs and fill the ring much more often with dummy work. We
have completely undone the outstanding_last_seqno optimisation.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93907
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
Cc: sta...@vger.kernel.org
---
  drivers/gpu/drm/i915/i915_drv.h|  2 --
  drivers/gpu/drm/i915/i915_gem.c| 50 --
  drivers/gpu/drm/i915/i915_gem_context.c| 21 ++---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 15 +++--
  drivers/gpu/drm/i915/intel_display.c   |  2 +-
  drivers/gpu/drm/i915/intel_lrc.c   |  4 +--
  drivers/gpu/drm/i915/intel_overlay.c   |  8 ++---
  7 files changed, 39 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a93e5dd4fa9a..f374db8de673 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2320,7 +2320,6 @@ struct drm_i915_gem_request {
  struct drm_i915_gem_request * __must_check
  i915_gem_request_alloc(struct intel_engine_cs *engine,
   struct intel_context *ctx);
-void i915_gem_request_cancel(struct drm_i915_gem_request *req);
  void i915_gem_request_free(struct kref *req_ref);
  int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
   struct drm_file *file);
@@ -2872,7 +2871,6 @@ int i915_gem_sw_finish_ioctl(struct drm_device *dev, void 
*data,
 struct drm_file *file_priv);
  void i915_gem_execbuffer_move_to_active(struct list_head *vmas,
struct drm_i915_gem_request *req);
-void i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params 
*params);
  int i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params,
   struct drm_i915_gem_execbuffer2 *args,
   struct list_head *vmas);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1c3ff56594d6..42227495803f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2753,7 +2753,8 @@ __i915_gem_request_alloc(struct intel_engine_cs *engine,
 * fully prepared. Thus it can be cleaned up using the proper
 * free code.
 */
-   i915_gem_request_cancel(req);
+   intel_ring_reserved_space_cancel(req->ringbuf);
+   i915_gem_request_unreference(req);
return ret;
}

@@ -2790,13 +2791,6 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
return err ? ERR_PTR(err) : req;
  }

-void i915_gem_request_cancel(struct drm_i915_gem_request *req)
-{
-   intel_ring_reserved_space_cancel(req->ringbuf);
-
-   i915_gem_request_unreference(req);
-}
-
  struct drm_i915_gem_request *
  

[Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

[Lionel Landwerlin]

Color management properties are a bit of an odd use case because
they're not marked as atomic properties. Currently we're not updating
the non atomic values so the drm_crtc_state is out of sync with the
values stored in the crtc object.

v2: Update non atomic values only if commit succeeds (Bob Paauwe)

v3: Do not access crtc_state after commit, use crtc->state (Maarten
Lankhorst)

Cc: Maarten Lankhorst 
Cc: Bob Paauwe 
Cc: 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/drm_atomic_helper.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 7bf678e..13b86cf 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2979,6 +2979,14 @@ retry:
if (ret)
goto fail;
 
+   drm_object_property_set_value(>base,
+   config->degamma_lut_property, 0);
+   drm_object_property_set_value(>base,
+   config->ctm_property, 0);
+   drm_object_property_set_value(>base,
+   config->gamma_lut_property,
+   crtc->state->gamma_lut->base.id);
+
/* Driver takes ownership of state on successful commit. */
 
drm_property_unreference_blob(blob);
-- 
2.8.0.rc3

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

Re: [Intel-gfx] [for-CI] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

[Chris Wilson]

On Mon, Apr 11, 2016 at 04:31:28PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 11, 2016 at 02:21:01PM +0100, Chris Wilson wrote:
> > This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
> 
> Not quite yet. I have patches pretty much line up to fix the resulting
> spew. Just got a bit sidetracked by the CHV irq problems.

Aye, this was just probing CI to see if we can get an explanation for
some [drm:cherryview_enable_rps] GT fifo had a previous error 108
in recent runs.
-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] test/gem_mocs_settings: Testing MOCS register settings

[Chris Wilson]

On Mon, Apr 11, 2016 at 01:51:25PM +0100, Peter Antoine wrote:
> The MOCS registers were added in Gen9 and define the caching policy.
> The registers are split into two sets. The first set controls the
> EDRAM policy and have a set for each engine, the second set controls
> the L3 policy. The two sets use the same index.
> 
> The RCS registers and the L3CC registers are stored in the RCS context.
> 
> The test checks that the registers are correct by checking the values by
> directly reading them via MMIO, then again it tests them by reading them
> from within a batch buffer. RCS engine is tested last as it programs the
> registers via a batch buffer and this will invalidate the test for
> workloads that don't use the render ring or don't run a render batch
> first.
> 
> v2: Reorganised the structure.
> Added more tests. (Chris Wilson)
> v3: Fixed a few bugs. (Chris Wilson)
> 
> Signed-off-by: Peter Antoine 
> ---
>  lib/ioctl_wrappers.c  |  13 ++
>  lib/ioctl_wrappers.h  |   1 +
>  tests/Makefile.sources|   1 +
>  tests/gem_mocs_settings.c | 559 
> ++
>  4 files changed, 574 insertions(+)
>  create mode 100644 tests/gem_mocs_settings.c
> 
> diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> index 076bce8..8d74128 100644
> --- a/lib/ioctl_wrappers.c
> +++ b/lib/ioctl_wrappers.c
> @@ -1382,6 +1382,19 @@ void gem_require_ring(int fd, unsigned ring)
>   igt_require(gem_has_ring(fd, ring));
>  }
>  
> +/**
> + * gem_has_mocs:
> + * @fd: open i915 drm file descriptor
> + *
> + * Feature test macro to query whether the device has MOCS registers.
> + * These exist gen 9+.
> + */
> +void gem_has_mocs(int fd)

gem_has_mocs() returns bool
gem_require_mocs() calls igt_require() and doesn't return if not
available.

> +{
> + const int gen = intel_gen(intel_get_drm_devid(fd));
> + igt_require(gen >= 9);
> +}
> +
>  /* prime */
>  
>  /**
> diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
> index d986f61..ebedf1e 100644
> --- a/lib/ioctl_wrappers.h
> +++ b/lib/ioctl_wrappers.h
> @@ -154,6 +154,7 @@ bool gem_has_softpin(int fd);
>  void gem_require_caching(int fd);
>  bool gem_has_ring(int fd, unsigned ring);
>  void gem_require_ring(int fd, unsigned ring);
> +void gem_has_mocs(int fd);
>  
>  /* prime */
>  struct local_dma_buf_sync {
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 43f232f..d483c9e 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -148,6 +148,7 @@ TESTS_progs = \
>   gem_lut_handle \
>   gem_mmap_offset_exhaustion \
>   gem_media_fill \
> + gem_mocs_settings \
>   gem_gpgpu_fill \
>   gem_pin \
>   gem_reg_read \
> diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
> new file mode 100644
> index 000..03c5089
> --- /dev/null
> +++ b/tests/gem_mocs_settings.c
> @@ -0,0 +1,559 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +/** @file gem_mocs_settings.c
> + *
> + * Check that the MOCs cache settings are valid.
> + */
> +
> +#include "igt.h"
> +#include "igt_gt.h"
> +
> +#define MAX_NUMBER_MOCS_REGISTERS(64)
> +
> +enum {
> + NONE,
> + RESET,
> + SUSPEND,
> + HIBERNATE
> +};
> +
> +#define GEN9_LNCFCMOCS0  (0xB020)/* L3 Cache Control 
> base */
> +#define GEN9_GFX_MOCS_0  (0xc800)/* Graphics MOCS base 
> register*/
> +#define GEN9_MFX0_MOCS_0 (0xc900)/* Media 0 MOCS base register*/
> +#define GEN9_MFX1_MOCS_0 (0xcA00)/* Media 1 MOCS base register*/
> +#define GEN9_VEBOX_MOCS_0(0xcB00)/* Video MOCS base register*/
> +#define GEN9_BLT_MOCS_0  (0xcc00)/* Blitter MOCS base 
> register*/
> +
> +#define ENGINE_GFX   

Re: [Intel-gfx] [for-CI] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

[Ville Syrjälä]

On Mon, Apr 11, 2016 at 02:21:01PM +0100, Chris Wilson wrote:
> This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.

Not quite yet. I have patches pretty much line up to fix the resulting
spew. Just got a bit sidetracked by the CHV irq problems.

> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index ac2ac07b505b..2f7fb7d169b8 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -633,15 +633,6 @@ __unclaimed_reg_debug(struct drm_i915_private *dev_priv,
> const bool read,
> const bool before)
>  {
> - /* XXX. We limit the auto arming traces for mmio
> -  * debugs on these platforms. There are just too many
> -  * revealed by these and CI/Bat suffers from the noise.
> -  * Please fix and then re-enable the automatic traces.
> -  */
> - if (i915.mmio_debug < 2 &&
> - (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> - return;
> -
>   if (WARN(check_for_unclaimed_mmio(dev_priv),
>"Unclaimed register detected %s %s register 0x%x\n",
>before ? "before" : "after",
> -- 
> 2.8.0.rc3
> 
> ___
> 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 v2] drm/i915: Fix eDP low vswing for Broadwell

[Ville Syrjälä]

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.
> 
> v2: Combine two if statements into one (Jani)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087
> Signed-off-by: Mika Kahola 

We didn't get a CI run for this?

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

Re: [Intel-gfx] [PATCH 12/16] drm/i915/bxt: Sanitize the DBUF HW state together with CDCLK

[Mika Kuoppala]

Imre Deak  writes:

> [ text/plain ]
> When determining whether CDCLK is enabled by BIOS and so we should skip
> reprogramming it, we didn't check the related DBUF power request and
> state. In theory BIOS could enable one without the other so check for
> this case and reprogram things if something is amiss.
>
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 28 ++--
>  1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 1fbe619..447d46e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5440,14 +5440,38 @@ static void broxton_set_cdclk(struct drm_i915_private 
> *dev_priv, int frequency)
>   intel_update_cdclk(dev_priv->dev);
>  }
>  
> +static bool broxton_cdclk_is_enabled(struct drm_i915_private *dev_priv)
> +{
> + if (!(I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_PLL_ENABLE))
> + return false;
> +
> + /* TODO: Check for a valid CDCLK rate */
> +

Discussed about the pll lock in irc with Imre. I think pll lock bit
should be included in the sanity inspection here too.

But that can be follow ups.

Reviewed-by: Mika Kuoppala 


> + if (!(I915_READ(DBUF_CTL) & DBUF_POWER_REQUEST)) {
> + DRM_DEBUG_DRIVER("CDCLK enabled, but DBUF power not 
> requested\n");
> +
> + return false;
> + }
> +
> + if (!(I915_READ(DBUF_CTL) & DBUF_POWER_STATE)) {
> + DRM_DEBUG_DRIVER("CDCLK enabled, but DBUF power hasn't 
> settled\n");
> +
> + return false;
> + }
> +
> + return true;
> +}
> +
>  void broxton_init_cdclk(struct drm_i915_private *dev_priv)
>  {
>   /* check if cd clock is enabled */
> - if (I915_READ(BXT_DE_PLL_ENABLE) & BXT_DE_PLL_PLL_ENABLE) {
> - DRM_DEBUG_KMS("Display already initialized\n");
> + if (broxton_cdclk_is_enabled(dev_priv)) {
> + DRM_DEBUG_KMS("CDCLK already enabled, won't reprogram it\n");
>   return;
>   }
>  
> + DRM_DEBUG_KMS("CDCLK not enabled, enabling it\n");
> +
>   /*
>* FIXME:
>* - The initial CDCLK needs to be read from VBT.
> -- 
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic function

[R, Durgadoss]

>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Monday, April 11, 2016 6:06 PM
>To: R, Durgadoss ; intel-gfx@lists.freedesktop.org
>Cc: ville.syrj...@linux.intel.com
>Subject: Re: [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic 
>function
>
>On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote:
>> Looping over the crtc list and finding an unused crtc
>> has other users like upfront link training. Hence move it to
>> a common function to re-use the logic.
>>
>> v3:
>> * Added kernel Doc and removed an invalid comment (Ander)
>> * Rebased on top of latest code which includes locking
>>   for state->enable usage.
>> v2:
>> * Made this as a separate function instead of having it
>>   inside upfront link train code.
>>
>> Signed-off-by: Durgadoss R 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 74 
>> +--
>> -
>>  drivers/gpu/drm/i915/intel_drv.h |  2 +
>>  2 files changed, 45 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index e6b5ee5..3c1fbcd 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -10366,6 +10366,43 @@ static int intel_modeset_setup_plane_state(struct
>> drm_atomic_state *state,
>>  return 0;
>>  }
>>
>> +/**
>> + * intel_get_unused_crtc - Find an unused crtc for the given encoder
>> + * @encoder: drm_encoder structure
>> + * @ctx: ctx pointer to use with locking
>> + *
>> + * This function tries to find an unused crtc that can drive
>> + * the given encoder. Returns NULL on failure.
>
>This doesn't match the code below, since it now returns an unused crtc or an
>ERR_PTR. It never returns NULL.

If the 'state->enable'  is set for all crtcs, then I think it can return a NULL.
Anyway, will fix the comment so say "Null or an error pointer" on failure.

Thanks,
Durga

>
>Ander
>
>> + */
>> +struct drm_crtc *intel_get_unused_crtc(struct drm_encoder *encoder,
>> +struct drm_modeset_acquire_ctx *ctx)
>> +{
>> +struct drm_crtc *possible_crtc;
>> +struct drm_crtc *crtc = NULL;
>> +struct drm_device *dev = encoder->dev;
>> +int ret, i = -1;
>> +
>> +for_each_crtc(dev, possible_crtc) {
>> +i++;
>> +if (!(encoder->possible_crtcs & (1 << i)))
>> +continue;
>> +
>> +ret = drm_modeset_lock(_crtc->mutex, ctx);
>> +if (ret)
>> +return ERR_PTR(ret);
>> +
>> +if (possible_crtc->state->enable) {
>> +drm_modeset_unlock(_crtc->mutex);
>> +continue;
>> +}
>> +
>> +crtc = possible_crtc;
>> +break;
>> +}
>> +
>> +return crtc;
>> +}
>> +
>>  bool intel_get_load_detect_pipe(struct drm_connector *connector,
>>  struct drm_display_mode *mode,
>>  struct intel_load_detect_pipe *old,
>> @@ -10374,7 +10411,6 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  struct intel_crtc *intel_crtc;
>>  struct intel_encoder *intel_encoder =
>>  intel_attached_encoder(connector);
>> -struct drm_crtc *possible_crtc;
>>  struct drm_encoder *encoder = _encoder->base;
>>  struct drm_crtc *crtc = NULL;
>>  struct drm_device *dev = encoder->dev;
>> @@ -10383,7 +10419,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  struct drm_atomic_state *state = NULL, *restore_state = NULL;
>>  struct drm_connector_state *connector_state;
>>  struct intel_crtc_state *crtc_state;
>> -int ret, i = -1;
>> +int ret;
>>
>>  DRM_DEBUG_KMS("[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
>>connector->base.id, connector->name,
>> @@ -10413,39 +10449,15 @@ retry:
>>  ret = drm_modeset_lock(>mutex, ctx);
>>  if (ret)
>>  goto fail;
>> -
>> -/* Make sure the crtc and connector are running */
>> -goto found;
>> -}
>> -
>> -/* Find an unused one (if possible) */
>> -for_each_crtc(dev, possible_crtc) {
>> -i++;
>> -if (!(encoder->possible_crtcs & (1 << i)))
>> -continue;
>> -
>> -ret = drm_modeset_lock(_crtc->mutex, ctx);
>> -if (ret)
>> +} else {
>> +crtc = intel_get_unused_crtc(encoder, ctx);
>> +if (IS_ERR_OR_NULL(crtc)) {
>> +ret = PTR_ERR_OR_ZERO(crtc);
>> +DRM_DEBUG_KMS("no pipe available for load-detect\n");
>>  goto fail;
>> -
>> -if (possible_crtc->state->enable) {
>> -drm_modeset_unlock(_crtc->mutex);
>> -continue;
>>  }
>> -
>> -crtc = possible_crtc;
>> -  

[Intel-gfx] [for-CI] Revert "drm/i915: Limit the auto arming of mmio debugs on vlv/chv"

[Chris Wilson]

This reverts commit c81eeea6c14b212016104f4256c65f93ad230a86.
---
 drivers/gpu/drm/i915/intel_uncore.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index ac2ac07b505b..2f7fb7d169b8 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -633,15 +633,6 @@ __unclaimed_reg_debug(struct drm_i915_private *dev_priv,
  const bool read,
  const bool before)
 {
-   /* XXX. We limit the auto arming traces for mmio
-* debugs on these platforms. There are just too many
-* revealed by these and CI/Bat suffers from the noise.
-* Please fix and then re-enable the automatic traces.
-*/
-   if (i915.mmio_debug < 2 &&
-   (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
-   return;
-
if (WARN(check_for_unclaimed_mmio(dev_priv),
 "Unclaimed register detected %s %s register 0x%x\n",
 before ? "before" : "after",
-- 
2.8.0.rc3

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

Re: [Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

[Peter Antoine]

On Mon, 11 Apr 2016, Chris Wilson wrote:


On Mon, Apr 11, 2016 at 01:50:16PM +0100, Peter Antoine wrote:

On Fri, 8 Apr 2016, Chris Wilson wrote:

+   execbuf.flags = I915_EXEC_SECURE | engine_id;
+
+   gem_execbuf(fd, );
+   gem_sync(fd, handle);


  ^ Papering over a bug in your code.

Hint: did you tell anyone that you were writing into the buffer?

Ok a write_domain and gem_wait.


gem_wait isn't required, the order is enforced by gem_execbuf followed
by gem_read or subsequent gem_set_domain (if using mmap interface).
The API is geared towards explicit domain management.
-Chris
Ok, done that. Will post a new version after you have had a chance to look 
at the version I just posted.


Peter.






--
   Peter Antoine (Android Graphics Driver Software Engineer)
   -
   Intel Corporation (UK) Limited
   Registered No. 1134945 (England)
   Registered Office: Pipers Way, Swindon SN3 1RJ
   VAT No: 860 2173 47
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

[Chris Wilson]

On Mon, Apr 11, 2016 at 01:50:16PM +0100, Peter Antoine wrote:
> On Fri, 8 Apr 2016, Chris Wilson wrote:
> >>+   execbuf.flags = I915_EXEC_SECURE | engine_id;
> >>+
> >>+   gem_execbuf(fd, );
> >>+   gem_sync(fd, handle);
> >
> >   ^ Papering over a bug in your code.
> >
> >Hint: did you tell anyone that you were writing into the buffer?
> Ok a write_domain and gem_wait.

gem_wait isn't required, the order is enforced by gem_execbuf followed
by gem_read or subsequent gem_set_domain (if using mmap interface).
The API is geared towards explicit domain management.
-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 v3] test/gem_mocs_settings: Testing MOCS register settings

[Peter Antoine]

The MOCS registers were added in Gen9 and define the caching policy.
The registers are split into two sets. The first set controls the
EDRAM policy and have a set for each engine, the second set controls
the L3 policy. The two sets use the same index.

The RCS registers and the L3CC registers are stored in the RCS context.

The test checks that the registers are correct by checking the values by
directly reading them via MMIO, then again it tests them by reading them
from within a batch buffer. RCS engine is tested last as it programs the
registers via a batch buffer and this will invalidate the test for
workloads that don't use the render ring or don't run a render batch
first.

v2: Reorganised the structure.
Added more tests. (Chris Wilson)
v3: Fixed a few bugs. (Chris Wilson)

Signed-off-by: Peter Antoine 
---
 lib/ioctl_wrappers.c  |  13 ++
 lib/ioctl_wrappers.h  |   1 +
 tests/Makefile.sources|   1 +
 tests/gem_mocs_settings.c | 559 ++
 4 files changed, 574 insertions(+)
 create mode 100644 tests/gem_mocs_settings.c

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 076bce8..8d74128 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1382,6 +1382,19 @@ void gem_require_ring(int fd, unsigned ring)
igt_require(gem_has_ring(fd, ring));
 }
 
+/**
+ * gem_has_mocs:
+ * @fd: open i915 drm file descriptor
+ *
+ * Feature test macro to query whether the device has MOCS registers.
+ * These exist gen 9+.
+ */
+void gem_has_mocs(int fd)
+{
+   const int gen = intel_gen(intel_get_drm_devid(fd));
+   igt_require(gen >= 9);
+}
+
 /* prime */
 
 /**
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index d986f61..ebedf1e 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -154,6 +154,7 @@ bool gem_has_softpin(int fd);
 void gem_require_caching(int fd);
 bool gem_has_ring(int fd, unsigned ring);
 void gem_require_ring(int fd, unsigned ring);
+void gem_has_mocs(int fd);
 
 /* prime */
 struct local_dma_buf_sync {
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 43f232f..d483c9e 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -148,6 +148,7 @@ TESTS_progs = \
gem_lut_handle \
gem_mmap_offset_exhaustion \
gem_media_fill \
+   gem_mocs_settings \
gem_gpgpu_fill \
gem_pin \
gem_reg_read \
diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
new file mode 100644
index 000..03c5089
--- /dev/null
+++ b/tests/gem_mocs_settings.c
@@ -0,0 +1,559 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+/** @file gem_mocs_settings.c
+ *
+ * Check that the MOCs cache settings are valid.
+ */
+
+#include "igt.h"
+#include "igt_gt.h"
+
+#define MAX_NUMBER_MOCS_REGISTERS  (64)
+
+enum {
+   NONE,
+   RESET,
+   SUSPEND,
+   HIBERNATE
+};
+
+#define GEN9_LNCFCMOCS0(0xB020)/* L3 Cache Control 
base */
+#define GEN9_GFX_MOCS_0(0xc800)/* Graphics MOCS base 
register*/
+#define GEN9_MFX0_MOCS_0   (0xc900)/* Media 0 MOCS base register*/
+#define GEN9_MFX1_MOCS_0   (0xcA00)/* Media 1 MOCS base register*/
+#define GEN9_VEBOX_MOCS_0  (0xcB00)/* Video MOCS base register*/
+#define GEN9_BLT_MOCS_0(0xcc00)/* Blitter MOCS base 
register*/
+
+#define ENGINE_GFX (I915_EXEC_RENDER)
+#define ENGINE_MFX0(I915_EXEC_BSD)
+#define ENGINE_MFX0_ALT(I915_EXEC_BSD | 1 << 13)
+#define ENGINE_MFX1(I915_EXEC_BSD | 2 << 13)
+#define ENGINE_BLT (I915_EXEC_BLT)
+#define ENGINE_VEBOX   (I915_EXEC_VEBOX)
+
+struct mocs_entry {
+   uint32_tcontrol_value;
+   uint16_tl3cc_value;
+};
+
+struct mocs_table {
+   uint32_t

Re: [Intel-gfx] [PATCH i-g-t v2] test/gem_mocs_settings: Testing MOCS register settings

[Peter Antoine]

On Fri, 8 Apr 2016, Chris Wilson wrote:


On Fri, Apr 08, 2016 at 05:44:13PM +0100, Peter Antoine wrote:

+static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc,
+uint32_t *batch,
+uint32_t dst_handle,
+uint32_t size,
+uint32_t reg_base)
+{
+   unsigned int index;
+   unsigned int offset = 0;
+
+   for (index = 0, offset = 0; index < size; index++, offset += 4)


offset = 0 twice

Ok will fix.



+   {
+   batch[offset]   = MI_STORE_REGISTER_MEM_64_BIT_ADDR;
+   batch[offset+1] = reg_base + (index * sizeof(uint32_t));
+   batch[offset+2] = index * sizeof(uint32_t); /* reloc */
+   batch[offset+3] = 0;
+
+   reloc[index].offset = (offset + 2) * sizeof(uint32_t);
+   reloc[index].delta = index * sizeof(uint32_t);
+   reloc[index].target_handle = dst_handle;


Missed something.

Ok. See the domain is missing.



+   }
+
+   batch[offset++] = MI_BATCH_BUFFER_END;
+   batch[offset++] = 0;
+
+   return offset * sizeof(uint32_t);
+}
+
+static void do_read_registers(int fd,
+ uint32_t ctx_id,
+ uint32_t dst_handle,
+ uint32_t reg_base,
+ uint32_t size,
+ uint32_t engine_id)
+{
+   struct drm_i915_gem_execbuffer2 execbuf;
+   struct drm_i915_gem_exec_object2 gem_exec[2];
+	struct drmB_i915_gem_relocation_entry 

reloc[MAX_NUMBER_MOCS_REGISTERS];

+   uint32_t batch[MAX_NUMBER_MOCS_REGISTERS * 4 + 4];
+   uint32_t handle = gem_create(fd, 4096);
+
+   memset(reloc, 0, sizeof(reloc));
+   memset(gem_exec, 0, sizeof(gem_exec));
+   memset(, 0, sizeof(execbuf));
+
+   gem_exec[0].handle = dst_handle;
+   gem_set_domain(fd, dst_handle, I915_GEM_DOMAIN_CPU, 0);


??

Ok. Not required.



+   gem_exec[1].handle = handle;
+   gem_exec[1].relocation_count = size;
+   gem_exec[1].relocs_ptr = (uintptr_t) reloc;
+
+   execbuf.buffers_ptr = (uintptr_t)gem_exec;
+   execbuf.buffer_count = 2;
+   execbuf.batch_len = create_read_batch(reloc,

B>> +   batch,

+ dst_handle,
+ size,
+ reg_base);
+
+   gem_write(fd, handle, 0, batch, execbuf.batch_len);
+
+   if (ctx_id != 0)
+   i915_execbuffer2_set_context_id(execbuf, ctx_id);


Just set it.

ok.



+
+   execbuf.flags = I915_EXEC_SECURE | engine_id;
+
+   gem_execbuf(fd, );
+   gem_sync(fd, handle);


   ^ Papering over a bug in your code.

Hint: did you tell anyone that you were writing into the buffer?

Ok a write_domain and gem_wait.



+
+   gem_close(fd, handle);
+}
+
+#define LOCAL_MI_LOAD_REGISTER_IMM (0x22 << 23)
+
+static int create_write_batch(uint32_t *batch,
+ const uint32_t *values,
+ uint32_t size,
+ uint32_t reg_base)
+{
+   unsigned int i;
+   unsigned int offset = 0;
+
+   batch[offset++] = LOCAL_MI_LOAD_REGISTER_IMM | (size * 2 - 1);
+
+   for (i = 0; i < size; i++) {
+   batch[offset++] = reg_base + (i * 4);
+   batch[offset++] = values[i];
+   }
+
+   batch[offset++] = 0;
+   batch[offset++] = MI_BATCH_BUFFER_END;
+   batch[offset++] = 0;
+
+   return offset * sizeof(uint32_t);
+}
+
+static void write_registers(int fd,
+   uint32_t ctx_id,
+   uint32_t reg_base,
+   const uint32_t *values,
+   uint32_t size,
+   uint32_t engine_id)
+{
+   struct drm_i915_gem_exec_object2 gem_exec;
+   struct drm_i915_gem_execbuffer2 execbuf;
+   uint32_t batch[MAX_NUMBER_MOCS_REGISTERS * 4 + 4];
+   uint32_t handle = gem_create(fd, 4096);
+
+   memset(_exec, 0, sizeof(gem_exec));
+   memset(, 0, sizeof(execbuf));
+
+   gem_exec.handle = handle;
+
+   execbuf.buffers_ptr = (uintptr_t)_exec;
+   execbuf.buffer_count = 1;
+   execbuf.batch_len = create_write_batch(batch, values, size, reg_base);
+
+   gem_write(fd, handle, 0, batch, execbuf.batch_len);
+
+   if (ctx_id != 0)
+   i915_execbuffer2_set_context_id(execbuf, ctx_id);
+
+   execbuf.flags = I915_EXEC_SECURE | engine_id;
+
+   gem_execbuf(fd, );
+   gem_sync(fd, handle);
+
+   gem_close(fd, handle);
+}
+
+static void check_control_registers(int fd,
+   const struct intel_execution_engine *engine,
+   uint32_t ctx_id,
+   bool dirty)
+{

Re: [Intel-gfx] [PATCH 01/16] drm/i915/bxt: Reject DMC firmware versions with known bugs

[Mika Kuoppala]

Imre Deak  writes:

> [ text/plain ]
> DMC version 1.06 has a known bug, where the firmware polls forever for a port
> PLL to lock, if the PLL was disabled when entering DC5. Version 1.07 fixes
> this, so make that the minimum required version on BXT.
>

If this would be for already released hw, we would need to be
more descriptive about the symptoms. Like 'it hangs the box'.

Reviewed-by: Mika Kuoppala 


> CC: Mika Kuoppala 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_csr.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index 3f57cb9..d57b00e 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -50,6 +50,7 @@ MODULE_FIRMWARE(I915_CSR_SKL);
>  MODULE_FIRMWARE(I915_CSR_BXT);
>  
>  #define SKL_CSR_VERSION_REQUIRED CSR_VERSION(1, 23)
> +#define BXT_CSR_VERSION_REQUIRED CSR_VERSION(1, 7)
>  
>  #define CSR_MAX_FW_SIZE  0x2FFF
>  #define CSR_DEFAULT_FW_OFFSET0x
> @@ -281,6 +282,7 @@ static uint32_t *parse_csr_fw(struct drm_i915_private 
> *dev_priv,
>   uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
>   uint32_t i;
>   uint32_t *dmc_payload;
> + uint32_t required_min_version;
>  
>   if (!fw)
>   return NULL;
> @@ -296,15 +298,23 @@ static uint32_t *parse_csr_fw(struct drm_i915_private 
> *dev_priv,
>  
>   csr->version = css_header->version;
>  
> - if ((IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) &&
> - csr->version < SKL_CSR_VERSION_REQUIRED) {
> - DRM_INFO("Refusing to load old Skylake DMC firmware v%u.%u,"
> + if (IS_SKYLAKE(dev_priv) || IS_KABYLAKE(dev_priv)) {
> + required_min_version = SKL_CSR_VERSION_REQUIRED;
> + } else if (IS_BROXTON(dev_priv)) {
> + required_min_version = BXT_CSR_VERSION_REQUIRED;
> + } else {
> + MISSING_CASE(INTEL_REVID(dev_priv));
> + required_min_version = 0;
> + }
> +
> + if (csr->version < required_min_version) {
> + DRM_INFO("Refusing to load old DMC firmware v%u.%u,"
>" please upgrade to v%u.%u or later"
>  " [" FIRMWARE_URL "].\n",
>CSR_VERSION_MAJOR(csr->version),
>CSR_VERSION_MINOR(csr->version),
> -  CSR_VERSION_MAJOR(SKL_CSR_VERSION_REQUIRED),
> -  CSR_VERSION_MINOR(SKL_CSR_VERSION_REQUIRED));
> +  CSR_VERSION_MAJOR(required_min_version),
> +  CSR_VERSION_MINOR(required_min_version));
>   return NULL;
>   }
>  
> -- 
> 2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI-ping,01/10] drm/i915: Force clean compilation with -Werror

[Patchwork]

== Series Details ==

Series: series starting with [CI-ping,01/10] drm/i915: Force clean compilation 
with -Werror
URL   : https://patchwork.freedesktop.org/series/5518/
State : failure

== Summary ==

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

Test gem_basic:
Subgroup bad-close:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup create-close:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_busy:
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-bsd:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
skip   -> PASS   (hsw-gt2)
Subgroup basic-vebox:
pass   -> SKIP   (bsw-nuc-2)
Test gem_ctx_create:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_param_basic:
Subgroup non-root-set-no-zeromap:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup root-set:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup root-set-no-zeromap-disabled:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ctx_switch:
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_basic:
Subgroup gtt-default:
pass   -> SKIP   (bsw-nuc-2)
Subgroup readonly-blt:
pass   -> SKIP   (bsw-nuc-2)
Subgroup readonly-render:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_store:
Subgroup basic-all:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_suspend:
Subgroup basic:
pass   -> SKIP   (bsw-nuc-2)
Test gem_exec_whisper:
Subgroup basic:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test gem_flink_basic:
Subgroup double-flink:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup flink-lifetime:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_linear_blits:
Subgroup basic:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test gem_mmap:
Subgroup basic-small-bo:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_mmap_gtt:
Subgroup basic-short:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-small-bo-tiledx:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-write-gtt-no-prefault:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-write-read:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup basic-write-read-distinct:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_pread:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_pwrite:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
Test gem_ringfill:
Subgroup basic-default-forked:
pass   -> SKIP   (bsw-nuc-2)
Test gem_storedw_loop:
Subgroup basic-blt:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-default:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
Subgroup basic-vebox:
pass   -> SKIP   (bsw-nuc-2)
Test gem_sync:
Subgroup basic-render:
pass   -> SKIP   (bsw-nuc-2)
Test kms_addfb_basic:
Subgroup addfb25-framebuffer-vs-set-tiling:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup addfb25-x-tiled:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bad-pitch-256:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bad-pitch-32:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup bad-pitch-63:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup framebuffer-vs-set-tiling:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup tile-pitch-mismatch:
pass   -> DMESG-WARN (bsw-nuc-2)
Subgroup unused-handle:
pass   -> DMESG-WARN (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> INCOMPLETE (bsw-nuc-2)
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-FAIL (bsw-nuc-2)
Subgroup basic-plain-flip:
pass   -> DMESG-FAIL (bsw-nuc-2)
Test kms_force_connector_basic:
Subgroup force-load-detect:
pass   -> SKIP   (ilk-hp8440p)

Re: [Intel-gfx] [PATCHv3 2/4] drm/i915: Store the dpll config in crtc_state->shared_dpll

[Conselvan De Oliveira, Ander]

On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote:
> Currently, the required shared dpll is saved in the crtc_state.
> Similarly, this patch saves the dpll config values also, so that
> these values (through crtc_state->shared_dpll->config.hw_state)
> can be used for upfront link training.
> 
> Signed-off-by: Durgadoss R 
> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 1175eeb..cad10f2 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -248,6 +248,7 @@ intel_reference_shared_dpll(struct intel_shared_dpll *pll,
>pipe_name(crtc->pipe));
>  
>   intel_shared_dpll_config_get(shared_dpll, pll, crtc);
> + crtc_state->shared_dpll->config = shared_dpll[i];

This overwrites the state stored in dev_priv->shared_dpll[i].config, so it means
we loose the current state set in the hardware. If the atomic check fails after
this, the software tracking of the hw state gets messed up.

Ander

>  }
>  
>  void intel_shared_dpll_commit(struct drm_atomic_state *state)
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic function

[Ander Conselvan De Oliveira]

On Wed, 2016-04-06 at 17:23 +0530, Durgadoss R wrote:
> Looping over the crtc list and finding an unused crtc
> has other users like upfront link training. Hence move it to
> a common function to re-use the logic.
> 
> v3:
> * Added kernel Doc and removed an invalid comment (Ander)
> * Rebased on top of latest code which includes locking
>   for state->enable usage.
> v2:
> * Made this as a separate function instead of having it
>   inside upfront link train code.
> 
> Signed-off-by: Durgadoss R 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 74 +--
> -
>  drivers/gpu/drm/i915/intel_drv.h |  2 +
>  2 files changed, 45 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e6b5ee5..3c1fbcd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10366,6 +10366,43 @@ static int intel_modeset_setup_plane_state(struct
> drm_atomic_state *state,
>   return 0;
>  }
>  
> +/**
> + * intel_get_unused_crtc - Find an unused crtc for the given encoder
> + * @encoder: drm_encoder structure
> + * @ctx: ctx pointer to use with locking
> + *
> + * This function tries to find an unused crtc that can drive
> + * the given encoder. Returns NULL on failure.

This doesn't match the code below, since it now returns an unused crtc or an
ERR_PTR. It never returns NULL.

Ander

> + */
> +struct drm_crtc *intel_get_unused_crtc(struct drm_encoder *encoder,
> + struct drm_modeset_acquire_ctx *ctx)
> +{
> + struct drm_crtc *possible_crtc;
> + struct drm_crtc *crtc = NULL;
> + struct drm_device *dev = encoder->dev;
> + int ret, i = -1;
> +
> + for_each_crtc(dev, possible_crtc) {
> + i++;
> + if (!(encoder->possible_crtcs & (1 << i)))
> + continue;
> +
> + ret = drm_modeset_lock(_crtc->mutex, ctx);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + if (possible_crtc->state->enable) {
> + drm_modeset_unlock(_crtc->mutex);
> + continue;
> + }
> +
> + crtc = possible_crtc;
> + break;
> + }
> +
> + return crtc;
> +}
> +
>  bool intel_get_load_detect_pipe(struct drm_connector *connector,
>   struct drm_display_mode *mode,
>   struct intel_load_detect_pipe *old,
> @@ -10374,7 +10411,6 @@ bool intel_get_load_detect_pipe(struct drm_connector
> *connector,
>   struct intel_crtc *intel_crtc;
>   struct intel_encoder *intel_encoder =
>   intel_attached_encoder(connector);
> - struct drm_crtc *possible_crtc;
>   struct drm_encoder *encoder = _encoder->base;
>   struct drm_crtc *crtc = NULL;
>   struct drm_device *dev = encoder->dev;
> @@ -10383,7 +10419,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
> *connector,
>   struct drm_atomic_state *state = NULL, *restore_state = NULL;
>   struct drm_connector_state *connector_state;
>   struct intel_crtc_state *crtc_state;
> - int ret, i = -1;
> + int ret;
>  
>   DRM_DEBUG_KMS("[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
> connector->base.id, connector->name,
> @@ -10413,39 +10449,15 @@ retry:
>   ret = drm_modeset_lock(>mutex, ctx);
>   if (ret)
>   goto fail;
> -
> - /* Make sure the crtc and connector are running */
> - goto found;
> - }
> -
> - /* Find an unused one (if possible) */
> - for_each_crtc(dev, possible_crtc) {
> - i++;
> - if (!(encoder->possible_crtcs & (1 << i)))
> - continue;
> -
> - ret = drm_modeset_lock(_crtc->mutex, ctx);
> - if (ret)
> + } else {
> + crtc = intel_get_unused_crtc(encoder, ctx);
> + if (IS_ERR_OR_NULL(crtc)) {
> + ret = PTR_ERR_OR_ZERO(crtc);
> + DRM_DEBUG_KMS("no pipe available for load-detect\n");
>   goto fail;
> -
> - if (possible_crtc->state->enable) {
> - drm_modeset_unlock(_crtc->mutex);
> - continue;
>   }
> -
> - crtc = possible_crtc;
> - break;
> - }
> -
> - /*
> -  * If we didn't find an unused CRTC, don't use any.
> -  */
> - if (!crtc) {
> - DRM_DEBUG_KMS("no pipe available for load-detect\n");
> - goto fail;
>   }
>  
> -found:
>   intel_crtc = to_intel_crtc(crtc);
>  
>   ret = drm_modeset_lock(>primary->mutex, ctx);
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9255b56..3873af5 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1152,6 

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id for legacy mode

[Chris Wilson]

On Mon, Apr 11, 2016 at 11:32:20AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id 
> for legacy mode
> URL   : https://patchwork.freedesktop.org/series/5515/
> State : failure
> 
> == Summary ==
> 
> Series 5515v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/5515/revisions/1/mbox/
> 
> Test drv_getparams_basic:
> Subgroup basic-eu-total:
> pass   -> DMESG-WARN (bdw-ultra)

Which boils down to a missing clear ppgtt dirty flag for gen8 and that
gen8 can with its many rings and a sempahore to each + flush exceed the
reserved space.
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id for legacy mode

[Patchwork]

== Series Details ==

Series: series starting with [for-CI,1/5] drm/i915: Fix gen8 semaphores id for 
legacy mode
URL   : https://patchwork.freedesktop.org/series/5515/
State : failure

== Summary ==

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

Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-subslice-total:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test drv_module_reload_basic:
incomplete -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_basic:
Subgroup bad-close:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
dmesg-warn -> PASS   (skl-i7k-2)
Subgroup create-close:
pass   -> DMESG-WARN (bdw-ultra)
dmesg-warn -> PASS   (skl-i7k-2)
Subgroup create-fd-close:
pass   -> DMESG-WARN (bdw-ultra)
Test gem_busy:
Subgroup basic-blt:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-bsd:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-render:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-vebox:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_ctx_basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
dmesg-warn -> PASS   (skl-i7k-2)
Test gem_ctx_create:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_ctx_exec:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_ctx_param_basic:
Subgroup basic:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-default:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup invalid-ctx-get:
pass   -> DMESG-WARN (bdw-ultra)
Subgroup invalid-ctx-set:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup invalid-param-get:
pass   -> DMESG-WARN (bdw-ultra)
dmesg-warn -> PASS   (skl-i7k-2)
Subgroup invalid-param-set:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup invalid-size-get:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup invalid-size-set:
pass   -> DMESG-WARN (bdw-ultra)
Subgroup non-root-set:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup non-root-set-no-zeromap:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup root-set:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup root-set-no-zeromap-disabled:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
dmesg-warn -> PASS   (skl-i7k-2)
Subgroup root-set-no-zeromap-enabled:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_ctx_switch:
Subgroup basic-default:
dmesg-fail -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Test gem_exec_basic:
Subgroup basic-blt:
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-bsd:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup basic-default:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> DMESG-WARN (bdw-ultra)
Subgroup 

[Intel-gfx] [CI-ping 07/10] drm/i915: Store the reset counter when constructing a request

[Chris Wilson]

As the request is only valid during the same global reset epoch, we can
record the current reset_counter when constructing the request and reuse
it when waiting upon that request in future. This removes a very hairy
atomic check serialised by the struct_mutex at the time of waiting and
allows us to transfer those waits to a central dispatcher for all
waiters and all requests.

PS: With per-engine resets, we obviously cannot assume a global reset
epoch for the requests - a per-engine epoch makes the most sense. The
challenge then is how to handle checking in the waiter for when to break
the wait, as the fine-grained reset may also want to requeue the
request (i.e. the assumption that just because the epoch changes the
request is completed may be broken - or we just avoid breaking that
assumption with the fine-grained resets).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 40 +++--
 drivers/gpu/drm/i915/intel_display.c|  7 +-
 drivers/gpu/drm/i915/intel_lrc.c|  7 --
 drivers/gpu/drm/i915/intel_ringbuffer.c |  6 -
 5 files changed, 15 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a4026babd43b..02e56161fac2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2243,6 +2243,7 @@ struct drm_i915_gem_request {
/** On Which ring this request was generated */
struct drm_i915_private *i915;
struct intel_engine_cs *engine;
+   unsigned reset_counter;
 
 /** GEM sequence number associated with the previous request,
  * when the HWS breadcrumb is equal to this the GPU is processing
@@ -3116,7 +3117,6 @@ void __i915_add_request(struct drm_i915_gem_request *req,
 #define i915_add_request_no_flush(req) \
__i915_add_request(req, NULL, false)
 int __i915_wait_request(struct drm_i915_gem_request *req,
-   unsigned reset_counter,
bool interruptible,
s64 *timeout,
struct intel_rps_client *rps);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2cab1786be79..80ca6bab3258 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1213,7 +1213,6 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)
 /**
  * __i915_wait_request - wait until execution of request has finished
  * @req: duh!
- * @reset_counter: reset sequence associated with the given request
  * @interruptible: do an interruptible wait (normally yes)
  * @timeout: in - how long to wait (NULL forever); out - how much time 
remaining
  *
@@ -1228,7 +1227,6 @@ static int __i915_spin_request(struct 
drm_i915_gem_request *req, int state)
  * errno with remaining time filled in timeout argument.
  */
 int __i915_wait_request(struct drm_i915_gem_request *req,
-   unsigned reset_counter,
bool interruptible,
s64 *timeout,
struct intel_rps_client *rps)
@@ -1290,7 +1288,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
 
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
-   if (reset_counter != i915_reset_counter(_priv->gpu_error)) {
+   if (req->reset_counter != 
i915_reset_counter(_priv->gpu_error)) {
/* ... but upgrade the -EAGAIN to an -EIO if the gpu
 * is truely gone. */
ret = i915_gem_check_wedge(_priv->gpu_error, 
interruptible);
@@ -1460,13 +1458,7 @@ i915_wait_request(struct drm_i915_gem_request *req)
 
BUG_ON(!mutex_is_locked(>struct_mutex));
 
-   ret = i915_gem_check_wedge(_priv->gpu_error, interruptible);
-   if (ret)
-   return ret;
-
-   ret = __i915_wait_request(req,
- i915_reset_counter(_priv->gpu_error),
- interruptible, NULL, NULL);
+   ret = __i915_wait_request(req, interruptible, NULL, NULL);
if (ret)
return ret;
 
@@ -1541,7 +1533,6 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
struct drm_device *dev = obj->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
-   unsigned reset_counter;
int ret, i, n = 0;
 
BUG_ON(!mutex_is_locked(>struct_mutex));
@@ -1550,12 +1541,6 @@ i915_gem_object_wait_rendering__nonblocking(struct 
drm_i915_gem_object *obj,
if (!obj->active)
return 0;
 
-   ret = 

[Intel-gfx] [CI-ping 05/10] drm/i915: Simplify checking of GPU reset_counter in display pageflips

[Chris Wilson]

If we, when we store the reset_counter for the operation, we ensure that
it is not in a wedged or in the middle of a reset, we can then assert that
if any reset occurs the reset_counter must change. Later we can just
compare the operation's reset epoch against the current counter to see
if we need to abort the operation (to handle the hang).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9e9d67008140..1af18484be1f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3198,14 +3198,12 @@ void intel_finish_reset(struct drm_device *dev)
 static bool intel_crtc_has_pending_flip(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
unsigned reset_counter;
bool pending;
 
-   reset_counter = i915_reset_counter(_priv->gpu_error);
-   if (intel_crtc->reset_counter != reset_counter ||
-   __i915_reset_in_progress_or_wedged(reset_counter))
+   reset_counter = i915_reset_counter(_i915(dev)->gpu_error);
+   if (intel_crtc->reset_counter != reset_counter)
return false;
 
spin_lock_irq(>event_lock);
@@ -10908,8 +10906,7 @@ static bool page_flip_finished(struct intel_crtc *crtc)
unsigned reset_counter;
 
reset_counter = i915_reset_counter(_priv->gpu_error);
-   if (crtc->reset_counter != reset_counter ||
-   __i915_reset_in_progress_or_wedged(reset_counter))
+   if (crtc->reset_counter != reset_counter)
return true;
 
/*
@@ -11571,8 +11568,13 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (ret)
goto cleanup;
 
-   atomic_inc(_crtc->unpin_work_count);
intel_crtc->reset_counter = i915_reset_counter(_priv->gpu_error);
+   if (__i915_reset_in_progress_or_wedged(intel_crtc->reset_counter)) {
+   ret = -EIO;
+   goto cleanup;
+   }
+
+   atomic_inc(_crtc->unpin_work_count);
 
if (INTEL_INFO(dev)->gen >= 5 || IS_G4X(dev))
work->flip_count = I915_READ(PIPE_FLIPCOUNT_G4X(pipe)) + 1;
-- 
2.8.0.rc3

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

[Intel-gfx] [CI-ping 03/10] drm/i915: Add GEM debugging Kconfig option

[Chris Wilson]

Currently there is a #define to enable extra BUG_ON for debugging
requests and associated activities. I want to expand its use to cover
all of GEM internals (so that we can saturate the code with asserts).
We can add a Kconfig option to make it easier to enable - with the usual
caveats of not enabling unless explicitly requested.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/Kconfig.debug | 12 
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_gem.c| 12 +---
 drivers/gpu/drm/i915/i915_gem.h| 34 ++
 4 files changed, 52 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem.h

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 61485c8ba3a8..8f404103341d 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -27,3 +27,15 @@ config DRM_I915_DEBUG
 
   If in doubt, say "N".
 
+config DRM_I915_DEBUG_GEM
+bool "Insert extra checks into the GEM internals"
+default n
+depends on DRM_I915_WERROR
+help
+  Enable extra sanity checks (including BUGs) along the GEM driver
+  paths that may slow the system down and if hit hang the machine.
+
+  Recommended for driver developers only.
+
+  If in doubt, say "N".
+
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1753077aebbc..fcecc0a7332f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -57,6 +57,7 @@
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
 
+#include "i915_gem.h"
 #include "i915_gem_gtt.h"
 #include "i915_gem_render_state.h"
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5a65a7663b88..716b7e00dd88 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -38,8 +38,6 @@
 #include 
 #include 
 
-#define RQ_BUG_ON(expr)
-
 static void i915_gem_object_flush_gtt_write_domain(struct drm_i915_gem_object 
*obj);
 static void i915_gem_object_flush_cpu_write_domain(struct drm_i915_gem_object 
*obj);
 static void
@@ -1521,7 +1519,7 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object 
*obj,
 
i915_gem_object_retire__read(obj, i);
}
-   RQ_BUG_ON(obj->active);
+   GEM_BUG_ON(obj->active);
}
 
return 0;
@@ -2422,8 +2420,8 @@ void i915_vma_move_to_active(struct i915_vma *vma,
 static void
 i915_gem_object_retire__write(struct drm_i915_gem_object *obj)
 {
-   RQ_BUG_ON(obj->last_write_req == NULL);
-   RQ_BUG_ON(!(obj->active & 
intel_engine_flag(obj->last_write_req->engine)));
+   GEM_BUG_ON(obj->last_write_req == NULL);
+   GEM_BUG_ON(!(obj->active & 
intel_engine_flag(obj->last_write_req->engine)));
 
i915_gem_request_assign(>last_write_req, NULL);
intel_fb_obj_flush(obj, true, ORIGIN_CS);
@@ -2434,8 +2432,8 @@ i915_gem_object_retire__read(struct drm_i915_gem_object 
*obj, int ring)
 {
struct i915_vma *vma;
 
-   RQ_BUG_ON(obj->last_read_req[ring] == NULL);
-   RQ_BUG_ON(!(obj->active & (1 << ring)));
+   GEM_BUG_ON(obj->last_read_req[ring] == NULL);
+   GEM_BUG_ON(!(obj->active & (1 << ring)));
 
list_del_init(>engine_list[ring]);
i915_gem_request_assign(>last_read_req[ring], NULL);
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
new file mode 100644
index ..8292e797d9b5
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#ifndef __I915_GEM_H__
+#define 

[Intel-gfx] [CI-ping 06/10] drm/i915: Tighten reset_counter for reset status

[Chris Wilson]

In the reset_counter, we use two bits to track a GPU hang and reset. The
low bit is a "reset-in-progress" flag that we set to signal when we need
to break waiters in order for the recovery task to grab the mutex. As
soon as the recovery task has the mutex, we can clear that flag (which
we do by incrementing the reset_counter thereby incrementing the gobal
reset epoch). By clearing that flag when the recovery task holds the
struct_mutex, we can forgo a second flag that simply tells GEM to ignore
the "reset-in-progress" flag.

The second flag we store in the reset_counter is whether the
reset failed and we consider the GPU terminally wedged. Whilst this flag
is set, all access to the GPU (at least through GEM rather than direct mmio
access) is verboten.

PS: Fun is in store, as in the future we want to move from a global
reset epoch to a per-engine reset engine with request recovery.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.c | 39 ++---
 drivers/gpu/drm/i915/i915_drv.h |  3 ---
 drivers/gpu/drm/i915/i915_gem.c | 27 +
 drivers/gpu/drm/i915/i915_irq.c | 21 ++--
 5 files changed, 36 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5def0c076ee2..70676fad8669 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4722,7 +4722,7 @@ i915_wedged_get(void *data, u64 *val)
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   *val = i915_reset_counter(_priv->gpu_error);
+   *val = i915_terminally_wedged(_priv->gpu_error);
 
return 0;
 }
@@ -4741,7 +4741,7 @@ i915_wedged_set(void *data, u64 val)
 * while it is writing to 'i915_wedged'
 */
 
-   if (i915_reset_in_progress_or_wedged(_priv->gpu_error))
+   if (i915_reset_in_progress(_priv->gpu_error))
return -EAGAIN;
 
intel_runtime_pm_get(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 29b4e79c85a6..310dc61817fa 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -880,23 +880,32 @@ int i915_resume_switcheroo(struct drm_device *dev)
 int i915_reset(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   bool simulated;
+   struct i915_gpu_error *error = _priv->gpu_error;
+   unsigned reset_counter;
int ret;
 
intel_reset_gt_powersave(dev);
 
mutex_lock(>struct_mutex);
 
-   i915_gem_reset(dev);
+   /* Clear any previous failed attempts at recovery. Time to try again. */
+   atomic_andnot(I915_WEDGED, >reset_counter);
 
-   simulated = dev_priv->gpu_error.stop_rings != 0;
+   /* Clear the reset-in-progress flag and increment the reset epoch. */
+   reset_counter = atomic_inc_return(>reset_counter);
+   if (WARN_ON(__i915_reset_in_progress(reset_counter))) {
+   ret = -EIO;
+   goto error;
+   }
+
+   i915_gem_reset(dev);
 
ret = intel_gpu_reset(dev, ALL_ENGINES);
 
/* Also reset the gpu hangman. */
-   if (simulated) {
+   if (error->stop_rings != 0) {
DRM_INFO("Simulated gpu hang, resetting stop_rings\n");
-   dev_priv->gpu_error.stop_rings = 0;
+   error->stop_rings = 0;
if (ret == -ENODEV) {
DRM_INFO("Reset not implemented, but ignoring "
 "error for simulated gpu hangs\n");
@@ -909,8 +918,7 @@ int i915_reset(struct drm_device *dev)
 
if (ret) {
DRM_ERROR("Failed to reset chip: %i\n", ret);
-   mutex_unlock(>struct_mutex);
-   return ret;
+   goto error;
}
 
intel_overlay_reset(dev_priv);
@@ -929,20 +937,14 @@ int i915_reset(struct drm_device *dev)
 * was running at the time of the reset (i.e. we weren't VT
 * switched away).
 */
-
-   /* Used to prevent gem_check_wedged returning -EAGAIN during gpu reset 
*/
-   dev_priv->gpu_error.reload_in_reset = true;
-
ret = i915_gem_init_hw(dev);
-
-   dev_priv->gpu_error.reload_in_reset = false;
-
-   mutex_unlock(>struct_mutex);
if (ret) {
DRM_ERROR("Failed hw init on reset %d\n", ret);
-   return ret;
+   goto error;
}
 
+   mutex_unlock(>struct_mutex);
+
/*
 * rps/rc6 re-init is necessary to restore state lost after the
 * reset and the re-install of gt irqs. Skip for ironlake per
@@ -953,6 +955,11 @@ int i915_reset(struct drm_device *dev)

[Intel-gfx] [CI-ping 09/10] drm/i915: Prevent leaking of -EIO from i915_wait_request()

[Chris Wilson]

Reporting -EIO from i915_wait_request() has proven very troublematic
over the years, with numerous hard-to-reproduce bugs cropping up in the
corner case of where a reset occurs and the code wasn't expecting such
an error.

If the we reset the GPU or have detected a hang and wish to reset the
GPU, the request is forcibly complete and the wait broken. Currently, we
report either -EAGAIN or -EIO in order for the caller to retreat and
restart the wait (if appropriate) after dropping and then reacquiring
the struct_mutex (essential to allow the GPU reset to proceed). However,
if we take the view that the request is complete (no further work will
be done on it by the GPU because it is dead and soon to be reset), then
we can proceed with the task at hand and then drop the struct_mutex
allowing the reset to occur. This transfers the burden of checking
whether it is safe to proceed to the caller, which in all but one
instance it is safe - completely eliminating the source of all spurious
-EIO.

Of note, we only have two API entry points where we expect that
userspace can observe an EIO. First is when submitting an execbuf, if
the GPU is terminally wedged, then the operation cannot succeed and an
-EIO is reported. Secondly, existing userspace uses the throttle ioctl
to detect an already wedged GPU before starting using HW acceleration
(or to confirm that the GPU is wedged after an error condition). So if
the GPU is wedged when the user calls throttle, also report -EIO.

v2: Split more carefully the change to i915_wait_request() and assorted
ABI from the reset handling.
v3: Add a couple of WARN_ON(EIO) to the interruptible modesetting code
so that we don't start to leak EIO there in future (and break our hang
resistant modesetting).

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 --
 drivers/gpu/drm/i915/i915_gem.c | 44 -
 drivers/gpu/drm/i915/i915_gem_userptr.c |  6 ++---
 drivers/gpu/drm/i915/intel_display.c| 13 +-
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  3 +--
 6 files changed, 32 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 02e56161fac2..97ff6eeb1f0c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3044,8 +3044,6 @@ i915_gem_find_active_request(struct intel_engine_cs 
*engine);
 
 bool i915_gem_retire_requests(struct drm_device *dev);
 void i915_gem_retire_requests_ring(struct intel_engine_cs *engine);
-int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
- bool interruptible);
 
 static inline u32 i915_reset_counter(struct i915_gpu_error *error)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 80ca6bab3258..04678942fc32 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -206,11 +206,10 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object 
*obj)
BUG_ON(obj->madv == __I915_MADV_PURGED);
 
ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (ret) {
+   if (WARN_ON(ret)) {
/* In the event of a disaster, abandon all caches and
 * hope for the best.
 */
-   WARN_ON(ret != -EIO);
obj->base.read_domains = obj->base.write_domain = 
I915_GEM_DOMAIN_CPU;
}
 
@@ -1105,15 +1104,13 @@ put_rpm:
return ret;
 }
 
-int
-i915_gem_check_wedge(struct i915_gpu_error *error,
-bool interruptible)
+static int
+i915_gem_check_wedge(unsigned reset_counter, bool interruptible)
 {
-   if (i915_reset_in_progress_or_wedged(error)) {
-   /* Recovery complete, but the reset failed ... */
-   if (i915_terminally_wedged(error))
-   return -EIO;
+   if (__i915_terminally_wedged(reset_counter))
+   return -EIO;
 
+   if (__i915_reset_in_progress(reset_counter)) {
/* Non-interruptible callers can't handle -EAGAIN, hence return
 * -EIO unconditionally for these. */
if (!interruptible)
@@ -1287,13 +1284,14 @@ int __i915_wait_request(struct drm_i915_gem_request 
*req,
prepare_to_wait(>irq_queue, , state);
 
/* We need to check whether any gpu reset happened in between
-* the caller grabbing the seqno and now ... */
+* the request being submitted and now. If a reset has occurred,
+* the request is effectively complete (we either are in the
+* process of or have discarded the rendering and completely
+* reset the GPU. The results of the request are lost and we
+* are free to continue 

[Intel-gfx] [CI-ping 10/10] drm/i915: Suppress error message when GPU resets are disabled

[Chris Wilson]

If we do not have lowlevel support for reseting the GPU, or if the user
has explicitly disabled reseting the device, the failure is expected.
Since it is an expected failure, we should be using a lower priority
message than *ERROR*, perhaps NOTICE. In the absence of DRM_NOTICE, just
emit the expected failure as a DEBUG message.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 310dc61817fa..18eb3e698763 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -917,7 +917,10 @@ int i915_reset(struct drm_device *dev)
pr_notice("drm/i915: Resetting chip after gpu hang\n");
 
if (ret) {
-   DRM_ERROR("Failed to reset chip: %i\n", ret);
+   if (ret != -ENODEV)
+   DRM_ERROR("Failed to reset chip: %i\n", ret);
+   else
+   DRM_DEBUG_DRIVER("GPU reset disabled\n");
goto error;
}
 
-- 
2.8.0.rc3

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

[Intel-gfx] [CI-ping 04/10] drm/i915: Hide the atomic_read(reset_counter) behind a helper

[Chris Wilson]

This is principally a little bit of syntatic sugar to hide the
atomic_read()s throughout the code to retrieve the current reset_counter.
It also provides the other utility functions to check the reset state on the
already read reset_counter, so that (in later patches) we can read it once
and do multiple tests rather than risk the value changing between tests.

v2: Be more strict on converting existing i915_reset_in_progress() over to
the more verbose i915_reset_in_progress_or_wedged().

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h | 32 
 drivers/gpu/drm/i915/i915_gem.c | 16 
 drivers/gpu/drm/i915/i915_irq.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c| 18 +++---
 drivers/gpu/drm/i915/intel_lrc.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  7 ---
 7 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9640738aabf2..5def0c076ee2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4722,7 +4722,7 @@ i915_wedged_get(void *data, u64 *val)
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   *val = atomic_read(_priv->gpu_error.reset_counter);
+   *val = i915_reset_counter(_priv->gpu_error);
 
return 0;
 }
@@ -4741,7 +4741,7 @@ i915_wedged_set(void *data, u64 val)
 * while it is writing to 'i915_wedged'
 */
 
-   if (i915_reset_in_progress(_priv->gpu_error))
+   if (i915_reset_in_progress_or_wedged(_priv->gpu_error))
return -EAGAIN;
 
intel_runtime_pm_get(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fcecc0a7332f..38f6dce05574 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3049,20 +3049,44 @@ void i915_gem_retire_requests_ring(struct 
intel_engine_cs *engine);
 int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
  bool interruptible);
 
+static inline u32 i915_reset_counter(struct i915_gpu_error *error)
+{
+   return atomic_read(>reset_counter);
+}
+
+static inline bool __i915_reset_in_progress(u32 reset)
+{
+   return unlikely(reset & I915_RESET_IN_PROGRESS_FLAG);
+}
+
+static inline bool __i915_reset_in_progress_or_wedged(u32 reset)
+{
+   return unlikely(reset & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
+}
+
+static inline bool __i915_terminally_wedged(u32 reset)
+{
+   return unlikely(reset & I915_WEDGED);
+}
+
 static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
 {
-   return unlikely(atomic_read(>reset_counter)
-   & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
+   return __i915_reset_in_progress(i915_reset_counter(error));
+}
+
+static inline bool i915_reset_in_progress_or_wedged(struct i915_gpu_error 
*error)
+{
+   return __i915_reset_in_progress_or_wedged(i915_reset_counter(error));
 }
 
 static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
 {
-   return atomic_read(>reset_counter) & I915_WEDGED;
+   return __i915_terminally_wedged(i915_reset_counter(error));
 }
 
 static inline u32 i915_reset_count(struct i915_gpu_error *error)
 {
-   return ((atomic_read(>reset_counter) & ~I915_WEDGED) + 1) / 2;
+   return ((i915_reset_counter(error) & ~I915_WEDGED) + 1) / 2;
 }
 
 static inline bool i915_stop_ring_allow_ban(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 716b7e00dd88..eb79a54c09bc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -83,7 +83,7 @@ i915_gem_wait_for_error(struct i915_gpu_error *error)
 {
int ret;
 
-#define EXIT_COND (!i915_reset_in_progress(error) || \
+#define EXIT_COND (!i915_reset_in_progress_or_wedged(error) || \
   i915_terminally_wedged(error))
if (EXIT_COND)
return 0;
@@ -1112,7 +1112,7 @@ int
 i915_gem_check_wedge(struct i915_gpu_error *error,
 bool interruptible)
 {
-   if (i915_reset_in_progress(error)) {
+   if (i915_reset_in_progress_or_wedged(error)) {
/* Non-interruptible callers can't handle -EAGAIN, hence return
 * -EIO unconditionally for these. */
if (!interruptible)
@@ -1299,7 +1299,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
 
/* We need to check whether any gpu reset happened in between
 * the caller grabbing the seqno and now ... */
-   if (reset_counter != 

[Intel-gfx] [CI-ping 02/10] drm/i915: Disentangle i915_drv.h includes

[Chris Wilson]

Separate out the layers of includes (linux, drm, intel, i915) so that it
is a little easier to order our definitions between our multiple
reentrant headers. A couple of headers needed fixes to make them more
standalone (forgotten includes, forward declarations etc).

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  | 29 +
 drivers/gpu/drm/i915/intel_guc.h |  2 ++
 drivers/gpu/drm/i915/intel_lrc.h |  2 ++
 3 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 542401659013..1753077aebbc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -33,27 +33,32 @@
 #include 
 #include 
 
-#include 
-#include "i915_params.h"
-#include "i915_reg.h"
-#include "intel_bios.h"
-#include "intel_ringbuffer.h"
-#include "intel_lrc.h"
-#include "i915_gem_gtt.h"
-#include "i915_gem_render_state.h"
 #include 
 #include 
 #include 
-#include 
-#include  /* for struct drm_dma_handle */
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include "intel_guc.h"
+#include 
+
+#include 
+#include 
+#include  /* for struct drm_dma_handle */
+#include 
+
+#include "i915_params.h"
+#include "i915_reg.h"
+
+#include "intel_bios.h"
 #include "intel_dpll_mgr.h"
+#include "intel_guc.h"
+#include "intel_lrc.h"
+#include "intel_ringbuffer.h"
+
+#include "i915_gem_gtt.h"
+#include "i915_gem_render_state.h"
 
 /* General customization:
  */
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 73002e901ff2..3bb85b127cb0 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -27,6 +27,8 @@
 #include "intel_guc_fwif.h"
 #include "i915_guc_reg.h"
 
+struct drm_i915_gem_request;
+
 struct i915_guc_client {
struct drm_i915_gem_object *client_obj;
struct intel_context *owner;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 0b0853eee91e..5136a2cf50b5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -24,6 +24,8 @@
 #ifndef _INTEL_LRC_H_
 #define _INTEL_LRC_H_
 
+#include "intel_ringbuffer.h"
+
 #define GEN8_LR_CONTEXT_ALIGN 4096
 
 /* Execlists regs */
-- 
2.8.0.rc3

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

[Intel-gfx] [CI-ping 01/10] drm/i915: Force clean compilation with -Werror

[Chris Wilson]

Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the patch.)

v2: Kick off a new "Debugging" submenu for i915.ko

At this point, we applied it to the kernel and promptly kicked it out
again as it broke buildbots (due to a compiler warning on 32bits):

commit 908d759b210effb33d927a8cb6603a16448474e4
Author: Daniel Vetter 
Date:   Tue May 26 07:46:21 2015 +0200

Revert "drm/i915: Force clean compilation with -Werror"

v3: Avoid enabling -Werror for allyesconfig/allmodconfig builds, using
COMPILE_TEST as a suitable proxy suggested by Andrew Morton. (Damien)
Only make the option available for EXPERT to reinforce that the option
should not be casually enabled.

Signed-off-by: Chris Wilson 
Cc: Jani Nikula 
Cc: Damien Lespiau 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/Kconfig.debug | 17 +
 drivers/gpu/drm/i915/Makefile  |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 649a562ddf17..61485c8ba3a8 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -1,3 +1,20 @@
+config DRM_I915_WERROR
+bool "Force GCC to throw an error instead of a warning when compiling"
+# As this may inadvertently break the build, only allow the user
+# to shoot oneself in the foot iff they aim really hard
+depends on EXPERT
+# We use the dependency on !COMPILE_TEST to not be enabled in
+# allmodconfig or allyesconfig configurations
+depends on !COMPILE_TEST
+default n
+help
+  Add -Werror to the build flags for (and only for) i915.ko.
+  Do not enable this unless you are writing code for the i915.ko 
module.
+
+  Recommended for driver developers only.
+
+  If in doubt, say "N".
+
 config DRM_I915_DEBUG
 bool "Enable additional driver debugging"
 depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b0cbc2..0b88ba0f3c1f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -2,6 +2,8 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
+subdir-ccflags-$(CONFIG_DRM_I915_WERROR) := -Werror
+
 # Please keep these build lists sorted!
 
 # core driver code
-- 
2.8.0.rc3

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: implement WaClearTdlStateAckDirtyBits (rev3)

[Tvrtko Ursulin]

On 22/03/16 07:32, Patchwork wrote:

== Series Details ==

Series: drm/i915: implement WaClearTdlStateAckDirtyBits (rev3)
URL   : https://patchwork.freedesktop.org/series/4282/
State : warning

== Summary ==

Series 4282v3 drm/i915: implement WaClearTdlStateAckDirtyBits
http://patchwork.freedesktop.org/api/1.0/series/4282/revisions/3/mbox/

Test kms_flip:
 Subgroup basic-flip-vs-wf_vblank:
 pass   -> DMESG-WARN (hsw-brixbox)
 Subgroup basic-plain-flip:
 pass   -> DMESG-WARN (snb-x220t)
 dmesg-warn -> PASS   (bdw-ultra)
Test kms_pipe_crc_basic:
 Subgroup read-crc-pipe-c-frame-sequence:
 pass   -> SKIP   (hsw-brixbox)
 Subgroup suspend-read-crc-pipe-c:
 dmesg-warn -> PASS   (bsw-nuc-2)
Test pm_rpm:
 Subgroup basic-pci-d3-state:
 pass   -> DMESG-WARN (snb-dellxps)
 pass   -> DMESG-WARN (byt-nuc)
 Subgroup basic-rte:
 dmesg-warn -> PASS   (snb-x220t)
 pass   -> DMESG-WARN (bsw-nuc-2)
 dmesg-warn -> PASS   (snb-dellxps)
 dmesg-warn -> PASS   (byt-nuc) UNSTABLE

bdw-nuci7total:192  pass:180  dwarn:0   dfail:0   fail:0   skip:12
bdw-ultratotal:192  pass:171  dwarn:0   dfail:0   fail:0   skip:21
bsw-nuc-2total:192  pass:154  dwarn:1   dfail:0   fail:0   skip:37
byt-nuc  total:192  pass:156  dwarn:1   dfail:0   fail:0   skip:35
hsw-brixbox  total:192  pass:168  dwarn:1   dfail:0   fail:0   skip:23
ilk-hp8440p  total:192  pass:128  dwarn:1   dfail:0   fail:0   skip:63
ivb-t430stotal:192  pass:167  dwarn:0   dfail:0   fail:0   skip:25
skl-i5k-2total:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23
skl-i7k-2total:192  pass:169  dwarn:0   dfail:0   fail:0   skip:23
snb-dellxps  total:192  pass:157  dwarn:1   dfail:0   fail:0   skip:34
snb-x220ttotal:192  pass:157  dwarn:1   dfail:0   fail:1   skip:33

Results at /archive/results/CI_IGT_test/Patchwork_1663/

4b39223f6e3bef4dfa678f7239dcd87c38e20e96 drm-intel-nightly: 
2016y-03m-21d-18h-43m-18s UTC integration manifest
8c4bb61d48749011ec44eaa2f908c1f4d48b601c drm/i915: implement 
WaClearTdlStateAckDirtyBits


Merged, thanks for the patch and review.

I have checked that the results from patchwork rev2 on which you replied 
still apply basically for rev3 as well.


There were also some checkpatch warnings on the patch which could have 
been avoided so please run it in the future and apply suggestions where 
not unreasonable.


Regards,

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

Re: [Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

[Maarten Lankhorst]

Op 11-04-16 om 12:37 schreef Lionel Landwerlin:
> Color management properties are a bit of an odd use case because
> they're not marked as atomic properties. Currently we're not updating
> the non atomic values so the drm_crtc_state is out of sync with the
> values stored in the crtc object.
>
> v2: Update non atomic values only if commit succeeds (Bob Paauwe)
>
> Cc: Maarten Lankhorst 
> Cc: Bob Paauwe 
> Cc: 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 7bf678e..65e55ce 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2979,6 +2979,14 @@ retry:
>   if (ret)
>   goto fail;
>  
> + drm_object_property_set_value(>base,
> + config->degamma_lut_property, 0);
> + drm_object_property_set_value(>base,
> + config->ctm_property, 0);
> + drm_object_property_set_value(>base,
> + config->gamma_lut_property,
> + crtc_state->gamma_lut->base.id);
> +
>   /* Driver takes ownership of state on successful commit. */
>  
>   drm_property_unreference_blob(blob);
You can't use crtc_state after drm_atomic_commit as it's freed, you need to use 
crtc->state.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [for-CI 3/5] drm/i915: Reload PD tables after semaphore wait on gen8

[Chris Wilson]

When the engine idles waiting upon a semaphore, it loses its
pagetables and we must reload them before executing the batch.

v2: Restrict w/a to non-RCS rings (RCS works correctly apparently).

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 32e0c9a8af57..2da8f4e68a7c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1446,6 +1446,7 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
 {
struct intel_engine_cs *waiter = waiter_req->engine;
struct drm_i915_private *dev_priv = waiter->dev->dev_private;
+   struct i915_hw_ppgtt *ppgtt;
int ret;
 
ret = intel_ring_begin(waiter_req, 4);
@@ -1461,6 +1462,15 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
intel_ring_emit(waiter,
upper_32_bits(GEN8_WAIT_OFFSET(waiter, signaller->id)));
intel_ring_advance(waiter);
+
+   /* When the !RCS engines idle waiting upon a semaphore, they lose their
+* pagetables and we must reload them before executing the batch.
+* We do this on the i915_switch_context() following the wait and
+* before the dispatch.
+*/
+   ppgtt = waiter_req->ctx->ppgtt;
+   if (ppgtt && waiter_req->engine->id != RCS)
+   ppgtt->pd_dirty_rings |= intel_engine_flag(waiter_req->engine);
return 0;
 }
 
-- 
2.8.0.rc3

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

[Intel-gfx] [for-CI 5/5] drm/i915: Enable legacy/semaphores for CI

[Chris Wilson]

---
 drivers/gpu/drm/i915/intel_lrc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index f209ecfdcb5c..53b0ffed2501 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -259,10 +259,6 @@ int intel_sanitize_enable_execlists(struct drm_device 
*dev, int enable_execlists
if (enable_execlists == 0)
return 0;
 
-   if (HAS_LOGICAL_RING_CONTEXTS(dev) && USES_PPGTT(dev) &&
-   i915.use_mmio_flip >= 0)
-   return 1;
-
return 0;
 }
 
-- 
2.8.0.rc3

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

[Intel-gfx] [for-CI 1/5] drm/i915: Fix gen8 semaphores id for legacy mode

[Chris Wilson]

With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a semaphore. Note that these values can be merged with engine->guc_id.

Fixes: de1add360522c876c25ef2ab1c94bdb509ab
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index e144f4f301bf..96ba147b8c98 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1307,7 +1307,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, seqno);
intel_ring_emit(signaller, 0);
intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL |
-  MI_SEMAPHORE_TARGET(waiter->id));
+  MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
 
@@ -1347,7 +1347,7 @@ static int gen8_xcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, upper_32_bits(gtt_offset));
intel_ring_emit(signaller, seqno);
intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL |
-  MI_SEMAPHORE_TARGET(waiter->id));
+  MI_SEMAPHORE_TARGET(waiter->hw_id));
intel_ring_emit(signaller, 0);
}
 
@@ -2798,6 +2798,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
engine->name = "render ring";
engine->id = RCS;
engine->exec_id = I915_EXEC_RENDER;
+   engine->hw_id = 0;
engine->mmio_base = RENDER_RING_BASE;
 
if (INTEL_INFO(dev)->gen >= 8) {
@@ -2949,6 +2950,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
engine->name = "bsd ring";
engine->id = VCS;
engine->exec_id = I915_EXEC_BSD;
+   engine->hw_id = 1;
 
engine->write_tail = ring_write_tail;
if (INTEL_INFO(dev)->gen >= 6) {
@@ -3027,6 +3029,7 @@ int intel_init_bsd2_ring_buffer(struct drm_device *dev)
engine->name = "bsd2 ring";
engine->id = VCS2;
engine->exec_id = I915_EXEC_BSD;
+   engine->hw_id = 4;
 
engine->write_tail = ring_write_tail;
engine->mmio_base = GEN8_BSD2_RING_BASE;
@@ -3059,6 +3062,7 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
engine->name = "blitter ring";
engine->id = BCS;
engine->exec_id = I915_EXEC_BLT;
+   engine->hw_id = 2;
 
engine->mmio_base = BLT_RING_BASE;
engine->write_tail = ring_write_tail;
@@ -3118,6 +3122,7 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev)
engine->name = "video enhancement ring";
engine->id = VECS;
engine->exec_id = I915_EXEC_VEBOX;
+   engine->hw_id = 3;
 
engine->mmio_base = VEBOX_RING_BASE;
engine->write_tail = ring_write_tail;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 78dc46864a10..4e52bbb3e436 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -156,7 +156,8 @@ struct  intel_engine_cs {
 #define I915_NUM_ENGINES 5
 #define _VCS(n) (VCS + (n))
unsigned int exec_id;
-   unsigned int guc_id;
+   unsigned int hw_id;
+   unsigned int guc_id; /* XXX same as hw_id? */
u32 mmio_base;
struct  drm_device *dev;
struct intel_ringbuffer *buffer;
-- 
2.8.0.rc3

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

[Intel-gfx] [for-CI 4/5] drm/i915: Enable semaphores for legacy submission on gen8

[Chris Wilson]

We have sufficient evidence from igt to support that semaphores are in
a working state. Enabling semaphores now for legacy provides a better
comparison of execlists against legacy ring submission.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 29b4e79c85a6..98f24474bc04 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -542,10 +542,6 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
if (i915.enable_execlists)
return false;
 
-   /* Until we get further testing... */
-   if (IS_GEN8(dev))
-   return false;
-
 #ifdef CONFIG_INTEL_IOMMU
/* Enable semaphores on SNB when IO remapping is off */
if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped)
-- 
2.8.0.rc3

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

[Intel-gfx] [for-CI 2/5] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

[Chris Wilson]

In order for the MI_SEMAPHORE_SIGNAL command to wait until after the
pipecontrol writing the signal value is complete, we have to pause the
CS inside the PIPE_CONTROL with the CS_STALL bit.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 96ba147b8c98..32e0c9a8af57 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1301,7 +1301,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request 
*signaller_req,
intel_ring_emit(signaller, GFX_OP_PIPE_CONTROL(6));
intel_ring_emit(signaller, PIPE_CONTROL_GLOBAL_GTT_IVB |
   PIPE_CONTROL_QW_WRITE |
-  PIPE_CONTROL_FLUSH_ENABLE);
+  PIPE_CONTROL_CS_STALL);
intel_ring_emit(signaller, lower_32_bits(gtt_offset));
intel_ring_emit(signaller, upper_32_bits(gtt_offset));
intel_ring_emit(signaller, seqno);
@@ -1454,7 +1454,6 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req,
 
intel_ring_emit(waiter, MI_SEMAPHORE_WAIT |
MI_SEMAPHORE_GLOBAL_GTT |
-   MI_SEMAPHORE_POLL |
MI_SEMAPHORE_SAD_GTE_SDD);
intel_ring_emit(waiter, seqno);
intel_ring_emit(waiter,
-- 
2.8.0.rc3

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

[Intel-gfx] [PATCH] drm: atomic: fix legacy gamma set helper

[Lionel Landwerlin]

Color management properties are a bit of an odd use case because
they're not marked as atomic properties. Currently we're not updating
the non atomic values so the drm_crtc_state is out of sync with the
values stored in the crtc object.

v2: Update non atomic values only if commit succeeds (Bob Paauwe)

Cc: Maarten Lankhorst 
Cc: Bob Paauwe 
Cc: 
Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/drm_atomic_helper.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 7bf678e..65e55ce 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2979,6 +2979,14 @@ retry:
if (ret)
goto fail;
 
+   drm_object_property_set_value(>base,
+   config->degamma_lut_property, 0);
+   drm_object_property_set_value(>base,
+   config->ctm_property, 0);
+   drm_object_property_set_value(>base,
+   config->gamma_lut_property,
+   crtc_state->gamma_lut->base.id);
+
/* Driver takes ownership of state on successful commit. */
 
drm_property_unreference_blob(blob);
-- 
2.8.0.rc3

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

Re: [Intel-gfx] [RFC 0/4] Eliminating the execlist retired request queue

[Chris Wilson]

On Mon, Apr 11, 2016 at 10:19:29AM +0100, Tvrtko Ursulin wrote:
> 
> On 09/04/16 09:03, Chris Wilson wrote:
> >On Fri, Apr 08, 2016 at 02:54:54PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>Retired request queue coupled with retired work handler is a scalability
> >>concern on some workloads of which one dramatic example is gem_close_race.
> >>
> >>This series depend on i915_gem_object_pin_map series by Chris Wilson.
> >
> >My biggest concern with this is that this touches code that has a known
> >GPF and so imo cannot be tested until that *regression* has been fixed.
> 
> That's the ringbuffer one or something else?

There's a GPF when we try to require a stale request because our state
tracking is caput.

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

Skylake was also misrendering under the same load, but that's likely to
be a different bug that I couldn't reproduce after fixing the above.
-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 drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit (rev2)

[Imre Deak]

On to, 2016-03-17 at 11:05 -0700, dw kim wrote:
> On Thu, Mar 17, 2016 at 01:03:36PM +, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit
> > (rev2)
> > URL   : https://patchwork.freedesktop.org/series/4491/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 4491v2 drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL
> > bit
> > http://patchwork.freedesktop.org/api/1.0/series/4491/revisions/2/mb
> > ox/
> > 
> > Test drv_module_reload_basic:
> > dmesg-warn -> PASS   (hsw-gt2)
> > Test gem_ringfill:
> > Subgroup basic-default-s3:
> > dmesg-warn -> PASS   (bsw-nuc-2)
> > Test kms_flip:
> > Subgroup basic-flip-vs-dpms:
> > dmesg-warn -> PASS   (bdw-ultra)
> > Subgroup basic-flip-vs-wf_vblank:
> > fail   -> PASS   (snb-x220t)
> > Subgroup basic-plain-flip:
> > pass   -> DMESG-WARN (hsw-gt2)
> > dmesg-warn -> PASS   (hsw-brixbox)
> > Test kms_force_connector_basic:
> > Subgroup prune-stale-modes:
> > pass   -> SKIP   (snb-x220t)
> > Test kms_pipe_crc_basic:
> > Subgroup read-crc-pipe-b-frame-sequence:
> > dmesg-warn -> PASS   (snb-x220t)
> > Subgroup read-crc-pipe-c-frame-sequence:
> > dmesg-warn -> PASS   (hsw-gt2)
> > Test pm_rpm:
> > Subgroup basic-pci-d3-state:
> > fail   -> DMESG-FAIL (snb-x220t)
> 
> This basic-pci-d3-state failure shouldn't be caused by
> this specific patch. It was filed in bugzilla a few months 
> back and hasn't been fixed yet.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=93123

All the above failures were due to the WM programming w/o powerref
issue which was fixed meanwhile.

Thanks for the patch I pushed it to drm-intel-next-queued.

--Imre

> 
> > Subgroup basic-rte:
> > dmesg-warn -> PASS   (hsw-brixbox)
> > 
> > bdw-
> > nuci7total:194  pass:182  dwarn:0   dfail:0   fail:0   skip
> > :12 
> > bdw-
> > ultratotal:194  pass:173  dwarn:0   dfail:0   fail:0   skip
> > :21 
> > bsw-nuc-
> > 2total:194  pass:157  dwarn:0   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:172  dwarn:0   dfail:0   fail:0   skip
> > :22 
> > 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 
> > snb-
> > x220ttotal:194  pass:159  dwarn:0   dfail:1   fail:0   skip
> > :34 
> > 
> > Results at /archive/results/CI_IGT_test/Patchwork_1628/
> > 
> > 8a9a911d489fe160df173580277983dac5952ed0 drm-intel-nightly: 2016y-
> > 03m-17d-10h-02m-10s UTC integration manifest
> > f432d2fe29fb024ac515e2ad2a7a8bb9700e6c70 drm/i915/bxt: Reversed
> > polarity of PORT_PLL_REF_SEL bit
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: implement WaClearTdlStateAckDirtyBits

[Arun Siluvery]

On 21/03/2016 14:37, tim.g...@intel.com wrote:

From: Tim Gore 

This is to fix a GPU hang seen with mid thread pre-emption
and pooled EUs.

v2. Use IS_BXT_REVID instead of IS_BROXTON and INTEL_REVID

v3. And use correct type for register addresses

Signed-off-by: Tim Gore 
---
  drivers/gpu/drm/i915/i915_reg.h  | 12 
  drivers/gpu/drm/i915/intel_lrc.c | 19 +++
  2 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 06fb589..c54190b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1783,6 +1783,18 @@ enum skl_disp_power_wells {
  #define   GEN9_IZ_HASHING_MASK(slice) (0x3 << ((slice) * 2))
  #define   GEN9_IZ_HASHING(slice, val) ((val) << ((slice) * 2))

+/* WaClearTdlStateAckDirtyBits */
+#define GEN8_STATE_ACK _MMIO(0x20F0)
+#define GEN9_STATE_ACK_SLICE1  _MMIO(0x20F8)
+#define GEN9_STATE_ACK_SLICE2  _MMIO(0x2100)
+#define   GEN9_STATE_ACK_TDL0 (1 << 12)
+#define   GEN9_STATE_ACK_TDL1 (1 << 13)
+#define   GEN9_STATE_ACK_TDL2 (1 << 14)
+#define   GEN9_STATE_ACK_TDL3 (1 << 15)
+#define   GEN9_SUBSLICE_TDL_ACK_BITS \
+   (GEN9_STATE_ACK_TDL3 | GEN9_STATE_ACK_TDL2 | \
+GEN9_STATE_ACK_TDL1 | GEN9_STATE_ACK_TDL0)
+
  #define GFX_MODE  _MMIO(0x2520)
  #define GFX_MODE_GEN7 _MMIO(0x229c)
  #define RING_MODE_GEN7(ring)  _MMIO((ring)->mmio_base+0x29c)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3a23b95..b6dcd4d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1450,6 +1450,25 @@ static int gen9_init_perctx_bb(struct intel_engine_cs 
*engine,
wa_ctx_emit(batch, index, MI_NOOP);
}

+   /* WaClearTdlStateAckDirtyBits:bxt */
+   if (IS_BXT_REVID(dev, 0, BXT_REVID_B0)) {
+   wa_ctx_emit(batch, index, MI_LOAD_REGISTER_IMM(4));
+
+   wa_ctx_emit_reg(batch, index, GEN8_STATE_ACK);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit_reg(batch, index, GEN9_STATE_ACK_SLICE1);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit_reg(batch, index, GEN9_STATE_ACK_SLICE2);
+   wa_ctx_emit(batch, index, 
_MASKED_BIT_DISABLE(GEN9_SUBSLICE_TDL_ACK_BITS));
+
+   wa_ctx_emit_reg(batch, index, GEN7_ROW_CHICKEN2);
+   /* dummy write to CS, mask bits are 0 to ensure the register is 
not modified */
+   wa_ctx_emit(batch, index, 0x0);
+   wa_ctx_emit(batch, index, MI_NOOP);
+   }
+
/* WaDisableCtxRestoreArbitration:skl,bxt */
if (IS_SKL_REVID(dev, 0, SKL_REVID_D0) ||
IS_BXT_REVID(dev, 0, BXT_REVID_A1))


sorry for the delay, it looks good to me,
Reviewed-by: Arun Siluvery 

regards
Arun


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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit

[Imre Deak]

On ke, 2016-03-16 at 18:06 -0700, Dongwon Kim wrote:
> For BXT, description of polarities of PORT_PLL_REF_SEL
> has been reversed for newer Gen9LP steppings according to the
> recent update in Bspec. This bit now should be set for
> "Non-SSC" mode for all Gen9LP starting from B0 stepping.
> 
> v2: Only B0 and newer stepping should be affected by this
> change.
> 
> Signed-off-by: Dongwon Kim 

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

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_dpll_mgr.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 4b636c4..c84589e 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1285,7 +1285,15 @@ static void bxt_ddi_pll_enable(struct
> drm_i915_private *dev_priv,
>   enum port port = (enum port)pll->id;/* 1:1 port->PLL 
> mapping */
>  
>   temp = I915_READ(BXT_PORT_PLL_ENABLE(port));
> - temp &= ~PORT_PLL_REF_SEL;
> + /*
> +  * Definition of each bit polarity has been changed
> +  * after A1 stepping
> +  */
> + if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1))
> + temp &= ~PORT_PLL_REF_SEL;
> + else
> + temp |= PORT_PLL_REF_SEL;
> +
>   /* Non-SSC reference */
>   I915_WRITE(BXT_PORT_PLL_ENABLE(port), temp);
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC] Prefer INTEL_INFO(dev_priv) to INTEL_INFO(dev)

[Jani Nikula]

On Mon, 11 Apr 2016, Dave Gordon  wrote:
> For this reason, I'd like to recommend that anyone doing this sort of 
> bulk transformation with Cocci or awk or just sed should /always/ 
> include the transformation script to help those with patches in flight.

I think that's generally the expectation anyway for cocci changes.

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 3/4] drm/i915: Restore GMBUS operation after a failed bit-banging fallback

[Jani Nikula]

On Mon, 07 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> When the GMBUS based i2c transfer times out, we try to fall back to
> bit-banging and retry the operation that way. However if the bit-banging
> attempt also fails, we should probably go back to the GMBUS method for
> the next attempt. Maybe there simply wasn't anyone one the bus at this
> time.
>
> There's also a bit of a mess going on with the force_bit handling.
> It's supposed to be a ref count actually, and it is as far as
> intel_gmbus_force_bit() is concerned. But it's treated as just a
> flag by the timeout based bit-banging fallback. I suppose that's
> fine since we should never end up in the timeout fallback case
> if force_bit was already non-zero. However now that we want to restore
> things back to where they were after the bit-banging attempt failed,
> we're going to have to do things a bit differently to avoid clobbering
> the force_bit count as set up by intel_gmbus_force_bit(). So let's
> dedicate the high bit as a flag for the low level timeout based fallback
> and treat the rest of the bits as a ref count just as before.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_i2c.c | 10 +++---
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f37ac120a29d..2348fea59592 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1043,6 +1043,7 @@ struct intel_fbc_work;
>  
>  struct intel_gmbus {
>   struct i2c_adapter adapter;
> +#define GMBUS_FORCE_BIT_RETRY (1U << 31)
>   u32 force_bit;
>   u32 reg0;
>   i915_reg_t gpio_reg;
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 7bf8a485e18f..5d4b3604afd2 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -579,7 +579,6 @@ timeout:
>* Hardware may not support GMBUS over these pins? Try GPIO bitbanging
>* instead. Use EAGAIN to have i2c core retry.
>*/
> - bus->force_bit = 1;
>   ret = -EAGAIN;
>  
>  out:
> @@ -597,10 +596,15 @@ gmbus_xfer(struct i2c_adapter *adapter, struct i2c_msg 
> *msgs, int num)
>   intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>   mutex_lock(_priv->gmbus_mutex);
>  
> - if (bus->force_bit)
> + if (bus->force_bit) {
>   ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
> - else
> + if (ret < 0)
> + bus->force_bit &= ~GMBUS_FORCE_BIT_RETRY;
> + } else {
>   ret = do_gmbus_xfer(adapter, msgs, num);
> + if (ret == -EAGAIN)
> + bus->force_bit |= GMBUS_FORCE_BIT_RETRY;

Hmm, would this all be simpler if we did the first bit-banging retry
here ourselves after all, and set ->force_bit only if bit-banging
succeeds after gmbus -EAGAIN? I think moving the retry out of
do_gmbus_xfer() was the right thing to do to, but maybe I went too far
by pushing it all the way to i2c core?

Anyway, this patch looks good, but it's just a bit subtle with the
-EAGAIN and one retry and all.

Up to you.

Reviewed-by: Jani Nikula 

> + }
>  
>   mutex_unlock(_priv->gmbus_mutex);
>   intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);

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

[Intel-gfx] [PATCH v2] drm/core: Add drm_accurate_vblank_count_and_time, v2.

[Maarten Lankhorst]

This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.

intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vblank handler has
run to completion. This function uses the timestamps to determine
when the last vblank has happened, and interpolates from there.

Changes since v1:
- Take vblank_time_lock and don't use drm_vblank_count_and_time.

Cc: Mario Kleiner 
Cc: Ville Syrjälä 
Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_irq.c | 31 +++
 include/drm/drmP.h|  2 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 3c1a6f18e71c..d3cecc1932e1 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -303,6 +303,37 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
store_vblank(dev, pipe, diff, _vblank, cur_vblank);
 }
 
+/**
+ * drm_accurate_vblank_count_and_time - retrieve the master vblank counter
+ * @crtc: which counter to retrieve
+ * @tv_ret: last time counter was updated
+ *
+ * This function is similar to @drm_update_vblank_count_and_time but
+ * this function interpolates to handle a race with vblank irq's, and
+ * is only useful for crtc's that have no hw vblank counter.
+ */
+
+u32 drm_accurate_vblank_count_and_time(struct drm_crtc *crtc,
+  struct timeval *tv_ret)
+{
+   struct drm_device *dev = crtc->dev;
+   u32 vblank, pipe = drm_crtc_index(crtc);
+   unsigned long flags;
+
+   WARN(dev->max_vblank_count, "This function is only useful when a hw 
counter is unavailable.");
+
+   spin_lock_irqsave(>vblank_time_lock, flags);
+   drm_update_vblank_count(dev, pipe, 0);
+
+   vblank = dev->vblank[pipe].count;
+   *tv_ret = vblanktimestamp(dev, pipe, vblank);
+
+   spin_unlock_irqrestore(>vblank_time_lock, flags);
+
+   return vblank;
+}
+EXPORT_SYMBOL(drm_accurate_vblank_count_and_time);
+
 /*
  * Disable vblank irq's on crtc, make sure that last vblank count
  * of hardware and corresponding consistent software vblank counter
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 31483c2fef51..1df65922c7c6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -995,6 +995,8 @@ extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
 extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
 extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
 extern void drm_vblank_cleanup(struct drm_device *dev);
+extern u32 drm_accurate_vblank_count_and_time(struct drm_crtc *crtc,
+ struct timeval *tv_ret);
 extern u32 drm_vblank_no_hw_counter(struct drm_device *dev, unsigned int pipe);
 
 extern int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
-- 
2.1.0


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

Re: [Intel-gfx] [RFC 4/4] drm/i915: Stop tracking execlists retired requests

[Chris Wilson]

On Mon, Apr 11, 2016 at 10:10:56AM +0100, Tvrtko Ursulin wrote:
> 
> On 08/04/16 15:57, Chris Wilson wrote:
> >On Fri, Apr 08, 2016 at 02:54:58PM +0100, Tvrtko Ursulin wrote:
> >>@@ -615,11 +613,6 @@ static void execlists_context_queue(struct 
> >>drm_i915_gem_request *request)
> >>struct drm_i915_gem_request *cursor;
> >>int num_elements = 0;
> >>
> >>-   if (request->ctx != request->i915->kernel_context)
> >>-   intel_lr_context_pin(request->ctx, engine);
> >>-
> >>-   i915_gem_request_reference(request);
> >>-
> >>spin_lock_bh(>execlist_lock);
> >>
> >>list_for_each_entry(cursor, >execlist_queue, execlist_link)
> >>@@ -636,11 +629,12 @@ static void execlists_context_queue(struct 
> >>drm_i915_gem_request *request)
> >>if (request->ctx == tail_req->ctx) {
> >>WARN(tail_req->elsp_submitted != 0,
> >>"More than 2 already-submitted reqs queued\n");
> >>-   list_move_tail(_req->execlist_link,
> >>-  >execlist_retired_req_list);
> >>+   list_del(_req->execlist_link);
> >>+   i915_gem_request_unreference(tail_req);
> >>}
> >>}
> >>
> >>+   i915_gem_request_reference(request);
> >>list_add_tail(>execlist_link, >execlist_queue);
> >
> >If you want to get truly radical, we do not need the ref on the request
> >until it is submitted to hardware. (As the request cannot be retired
> >until it has done so, it can leave the execlist_queue until we commit it
> >to hw, or perform the cancel).
> 
> Don't know. It is simple and nice that reference is tied to presence
> on execlist_queue.
> 
> More importantly, the patch as presented has a flaw that it
> dereferences req->ctx from execlists_check_remove_request where the
> context pin may have disappeared already due context complete
> interrupts getting behind when coallescing.
> 
> I will need to cache ctx_id in the request I think. It is fine do to
> that since ctx id must be unique and stable for a request.

For comparison, tracking by requests rather than contexts:

https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet=e23791ef88636aa6e3f850b61ab2c4e027af0e52
-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] [RFC] Prefer INTEL_INFO(dev_priv) to INTEL_INFO(dev)

[Dave Gordon]

On 08/04/16 07:09, Joonas Lahtinen wrote:

On to, 2016-04-07 at 18:57 +0100, Dave Gordon wrote:

Where we have a suitable dev_priv pointer, we can use that rather than
'dev' for accessing INTEL_INFO().  This removes one level of memory
reference, decreasing code size a little and possibly making everything
a little faster. We could also do this for all the macros that implicitly
use INTEL_INFO e.g. IS_CHERRYVIEW().


If applied to all macros, sounds like the right thing to do. Although,
I would prefer to see s/dev_priv/i915/g and then i915->info.gen, i915-

info.is_cherryview etc. rather than dozens of macros.


Maybe, but not all callsites actually have a 'dev_priv' in scope at 
present, which is why this had to be done with Coccinelle rather than 
just sed.


I tried extending this to all IS_XXX() macros as well (but not as yet 
HAS_XXX()) and got:


 36 files changed, 741 insertions(+), 763 deletions(-)

the line count difference being due to 22 now-unused local variables 
deleted afterwards; the i915.ko binary shrank by about 2k - which 
represents quite a lot of instructions. So this isn't just a matter of 
style, like changing INTEL_INFO(dev)->gen with INTEL_GEN(dev), this 
transformation actually improves code size and presumably speed :)



It's going to cause a lot of rebasing, though. So depending on when we
apply dev_priv -> i915, might be or might not be worth the hassle now.

Regards, Joonas


The point of including the actual Cocci code in the commit message is 
that then anyone who has a set of not-yet-submitted changes can apply 
the Cocci script to their own codebase before attempting to rebase onto 
the new version of nightly, thus eliminating from the conflicts all 
those which are simply due to the patch applied to upstream.


For this reason, I'd like to recommend that anyone doing this sort of 
bulk transformation with Cocci or awk or just sed should /always/ 
include the transformation script to help those with patches in flight.


.Dave.


Coccinelle:

 @dev_priv_param@
   function FUNC;
   idexpression struct drm_device *DEV;
   identifier DEV_PRIV;
 @@
   FUNC(..., struct drm_i915_private *DEV_PRIV, ...)
   {
<...
INTEL_INFO
(
 - DEV
 + DEV_PRIV
)
...>
   }

 @dev_priv_local@
   idexpression struct drm_device *DEV;
   identifier DEV_PRIV;
   expression E;
 @@
   {
...
 (
struct drm_i915_private *DEV_PRIV;
 |
struct drm_i915_private *DEV_PRIV = E;
 )
<...
INTEL_INFO
(
 - DEV
 + DEV_PRIV
)
...>
   }

followed by manually deleting 6 now-unused "dev" locals.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_debugfs.c|  66 +++---
  drivers/gpu/drm/i915/i915_dma.c|  30 +++---
  drivers/gpu/drm/i915/i915_drv.c|   4 +-
  drivers/gpu/drm/i915/i915_gem.c|   6 +-
  drivers/gpu/drm/i915/i915_gem_context.c|   2 +-
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   8 +-
  drivers/gpu/drm/i915/i915_gem_fence.c  |   8 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c|  14 +--
  drivers/gpu/drm/i915/i915_gem_stolen.c |   6 +-
  drivers/gpu/drm/i915/i915_gpu_error.c  |  32 +++
  drivers/gpu/drm/i915/i915_irq.c|  36 
  drivers/gpu/drm/i915/i915_suspend.c|  20 ++--
  drivers/gpu/drm/i915/intel_color.c |  16 ++--
  drivers/gpu/drm/i915/intel_crt.c   |   6 +-
  drivers/gpu/drm/i915/intel_ddi.c   |   4 +-
  drivers/gpu/drm/i915/intel_display.c   | 141 ++---
  drivers/gpu/drm/i915/intel_dp.c|  20 ++--
  drivers/gpu/drm/i915/intel_dpll_mgr.c  |   2 +-
  drivers/gpu/drm/i915/intel_fbdev.c |   4 +-
  drivers/gpu/drm/i915/intel_lrc.c   |   2 +-
  drivers/gpu/drm/i915/intel_lvds.c  |   4 +-
  drivers/gpu/drm/i915/intel_overlay.c   |   4 +-
  drivers/gpu/drm/i915/intel_pm.c|  50 +-
  drivers/gpu/drm/i915/intel_psr.c   |   6 +-
  drivers/gpu/drm/i915/intel_ringbuffer.c|  40 
  drivers/gpu/drm/i915/intel_sdvo.c  |   8 +-
  drivers/gpu/drm/i915/intel_tv.c|   2 +-
  drivers/gpu/drm/i915/intel_uncore.c|   6 +-
  28 files changed, 270 insertions(+), 277 deletions(-)


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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Protect force_bit with gmbus_mutex

[Jani Nikula]

On Mon, 07 Mar 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Extend the protection of gmbus_mutex around the force_bit
> RMW in intel_gmbus_force_bit(), in case someone gets the
> idea of calling it from a separate thread while there's
> other stuff happening on the same bus.
>
> Signed-off-by: Ville Syrjälä 

intel_gmbus_is_forced_bit() usage in intel_crt_get_edid() seems a bit
suspect still, but this is a step forward.

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/i915/intel_i2c.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c 
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 52fbe530fc9e..7bf8a485e18f 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -718,11 +718,16 @@ void intel_gmbus_set_speed(struct i2c_adapter *adapter, 
> int speed)
>  void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit)
>  {
>   struct intel_gmbus *bus = to_intel_gmbus(adapter);
> + struct drm_i915_private *dev_priv = bus->dev_priv;
> +
> + mutex_lock(_priv->gmbus_mutex);
>  
>   bus->force_bit += force_bit ? 1 : -1;
>   DRM_DEBUG_KMS("%sabling bit-banging on %s. force bit now %d\n",
> force_bit ? "en" : "dis", adapter->name,
> bus->force_bit);
> +
> + mutex_unlock(_priv->gmbus_mutex);
>  }
>  
>  void intel_teardown_gmbus(struct drm_device *dev)

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