Re: [Intel-gfx] [PATCH] drm/i915: Support to create uncached user mapping for a Gem object

[Chris Wilson]

On Tue, Dec 09, 2014 at 08:48:38PM -0800, Chad Versace wrote:
> 
> 
> On 10/23/2014 06:23 AM, Chris Wilson wrote:
> > On Thu, Oct 23, 2014 at 12:56:46PM +0100, Chris Wilson wrote:
> >> On Thu, Oct 23, 2014 at 04:03:56PM +0530, akash.g...@intel.com wrote:
> >>> From: Akash Goel 
> >>>
> >>
> >>> This is for improving the CPU write operation performance, as with such
> >>> mapping, writes are almost 50% faster than with mmap_gtt. Also it avoids 
> >>> the
> 
> 
> > Oops, bugs beware. I wasn't calling the ioctl correctly.
> > Having re-run the test, I now get:
> > 
> >gtt   wcOperation
> >   --   -
> > 424000.01.30   ShmPutImage 10x10 square 
> >  29500.01.44   ShmPutImage 100x100 square 
> >   1510.01.38   ShmPutImage 500x500 square 
> > 
> > Supporting your claims. Very nice.
> 
> What are the units for these numbers?

ops/s, relative factor on a baby byt.
-Chris

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

[Intel-gfx] [PATCH] drm/i915: Quietly reject attempts to create non-pagealigned stolen objects

[Chris Wilson]

This added as a BUG_ON as it considered that no one would ever request
an unaligned object. However, it turns out that some BIOSes will
allocate a scanout that is offset from 0 and not aligned to a page
boundary, and we were passing this through and hitting the BUG_ON during
boot.

Quietly reject such a request to reserve the unaligned stolen object and
let the boot continue, restoring previous behaviour (i.e. no BIOS
framebuffer preservation).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883
Signed-off-by: Chris Wilson 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_gem_stolen.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 5c616ec2c5c8..a3bc0fa07c6c 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -646,13 +646,15 @@ i915_gem_object_create_stolen_for_preallocated(struct 
drm_device *dev,
DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, 
gtt_offset=%x, size=%x\n",
stolen_offset, gtt_offset, size);
 
-   /* KISS and expect everything to be page-aligned */
-   BUG_ON(stolen_offset & 4095);
-   BUG_ON(size & 4095);
-
if (WARN_ON(size == 0))
return NULL;
 
+   /* KISS and expect everything to be GTT page-aligned */
+   if ((stolen_offset | size) & 4095) {
+   DRM_DEBUG_KMS("request for unaligned stolen object, denied\n");
+   return NULL;
+   }
+
stolen = kzalloc(sizeof(*stolen), GFP_KERNEL);
if (!stolen)
return NULL;
-- 
2.1.3

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

Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: add component support

[Jani Nikula]

On Tue, 09 Dec 2014, Imre Deak  wrote:
> Register a component to be used to interface with the snd_hda_intel
> driver. This is meant to replace the same interface that is currently
> based on module symbol lookup.
>
> v2:
> - change roles between the hda and i915 components (Daniel)
> - add the implementation to a new file (Jani)
> - use better namespacing (Jani)
> v3:
> - move the implementation to intel_audio.c (Daniel)
> - rename display_component to audio_component (Daniel)
> - add kerneldoc (Daniel)
>
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_component.c |  27 +

Ooops?

J.

>  drivers/gpu/drm/i915/i915_dma.c   |   4 ++
>  drivers/gpu/drm/i915/i915_drv.h   |   3 +
>  drivers/gpu/drm/i915/intel_audio.c| 110 
> ++
>  drivers/gpu/drm/i915/intel_drv.h  |   2 +
>  include/drm/i915_component.h  |  38 
>  6 files changed, 184 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/i915_component.c
>  create mode 100644 include/drm/i915_component.h
>
> diff --git a/drivers/gpu/drm/i915/i915_component.c 
> b/drivers/gpu/drm/i915/i915_component.c
> new file mode 100644
> index 000..95dd087
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_component.c
> @@ -0,0 +1,27 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +#include "intel_drv.h"
> +
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 887d88f..f6334d0 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -830,6 +830,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> long flags)
>  
>   intel_runtime_pm_enable(dev_priv);
>  
> + i915_audio_component_init(dev_priv);
> +
>   return 0;
>  
>  out_power_well:
> @@ -870,6 +872,8 @@ int i915_driver_unload(struct drm_device *dev)
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   int ret;
>  
> + i915_audio_component_cleanup(dev_priv);
> +
>   ret = i915_gem_suspend(dev);
>   if (ret) {
>   DRM_ERROR("failed to idle hardware: %d\n", ret);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0961d7f..3c2d9c7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1713,6 +1713,9 @@ struct drm_i915_private {
>   struct drm_property *broadcast_rgb_property;
>   struct drm_property *force_audio_property;
>  
> + /* hda/i915 audio component */
> + bool audio_component_registered;
> +
>   uint32_t hw_context_size;
>   struct list_head context_list;
>  
> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> b/drivers/gpu/drm/i915/intel_audio.c
> index 2c7ed5c..ee41b88 100644
> --- a/drivers/gpu/drm/i915/intel_audio.c
> +++ b/drivers/gpu/drm/i915/intel_audio.c
> @@ -22,6 +22,9 @@
>   */
>  
>  #include 
> +#include 
> +#include 
> +#include "intel_drv.h"
>  
>  #include 
>  #include 
> @@ -461,3 +464,110 @@ void intel_init_audio(struct drm_device *dev)
>   dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
>   }
>  }
> +
> +static void i915_audio_component_get_power(struct device *dev)
> +{
> + intel_display_power_get(dev_to_i915(dev), POWER_DOMAIN_AUDIO);
> +}
> +
> +static void i915_audio_component_put_power(struct device *dev)
> +{
> + intel_display_power_put(dev_to_i915(dev), POWER_DOMAIN_AUDIO);
> +}
> +
> +/* Get CDCLK in kHz  */
> +static int i915_audio_component_get_cdclk_freq(struct device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev_to_i915(dev);
> + int ret;
> +
> + if (WARN_ON_ONCE(!HAS_DDI(dev_priv)))
> + return -ENODEV;
> +
> + intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
> + ret = intel_ddi_get_cdcl

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Add gpu hw state capture helper

[Chris Wilson]

On Tue, Dec 09, 2014 at 06:04:31PM +0200, Mika Kuoppala wrote:
> In the following commits, we want to capture the hw state
> also without any errors. Carve out the helper out from error
> capture parts.

As an aside i915_gpu_state is a better name throughout for struct
drm_i915_error_state. Afterwards, only the i915_gpu_state singleton we
capture upon a hang gets associated with the actual error state.
-Chris

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

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Specify bsd rings through exec flag

[Daniel Vetter]

On Wed, Dec 10, 2014 at 02:18:15AM +, Gong, Zhipeng wrote:
> On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
> > On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:
> > > On Tue, Nov 25, 2014 at 5:04 AM, Daniel Vetter  wrote:
> > > > On Mon, Nov 24, 2014 at 08:29:40AM -0800, Rodrigo Vivi wrote:
> > > >> From: Zhipeng Gong 
> > > >>
> > > >> On Broadwell GT3 we have 2 Video Command Streamers (VCS), but userspace
> > > >> has no control when using VCS1 or VCS2. This patch introduces a 
> > > >> mechanism
> > > >> to avoid the default ping-pong mode and use one specific ring through
> > > >> execution flag.
> > > >>
> > > >> v2: fix whitespace (Rodrigo)
> > > >> v3: remove incorrect chunk that came on -collector rebase. (Rodrigo)
> > > >>
> > > >> Signed-off-by: Zhipeng Gong 
> > > >> Reviewed-by-by: Rodrigo Vivi 
> > > >> Signed-off-by: Rodrigo Vivi 
> > > >
> > > > There's review from me pending on testcases and stuff, but I get the
> > > > impression that's lost now. Is it?
> > > 
> > > tests are ready as well, I've tested and reviewed them.
> > > imho this is ready for merge. Anyway I'm going to submit again on next
> > > -collector round
> > 
> > Last time I've looked it doesn't really address my review. Quoting
> > relevant parts:
> > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> > > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > index e1ed85a..d9081ec 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > > @@ -1273,8 +1273,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, 
> > > void *data,
> > >   else if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
> > >   if (HAS_BSD2(dev)) {
> > >   int ring_id;
> > > - ring_id = gen8_dispatch_bsd_ring(dev, file);
> > > - ring = &dev_priv->ring[ring_id];
> > > +
> > > + switch (args->flags & I915_EXEC_BSD_MASK) {
> > > + case I915_EXEC_BSD_DEFAULT:
> > > + ring_id = gen8_dispatch_bsd_ring(dev, file);
> > > + ring = &dev_priv->ring[ring_id];
> > > + break;
> > > + case I915_EXEC_BSD_RING1:
> > > + ring = &dev_priv->ring[VCS];
> > 
> > Do we have any use-case for selecting ring1 specifically? I've thought
> > it's only ring2 that is special?
> The HEVC GPU commands should be dispatched to BSD RING 1 instead of BSD
> RING2 as the two rings are asymmetrical. 
> For the H264 decoding/encoding either ring is OK.

Well then same arguments applies with ring2 since only ring1 is special?
It's just to minimize abi and reduce the amount of rope we hand to
userspace.

> > > + break;
> > > + case I915_EXEC_BSD_RING2:
> > 
> > This needs a if (!IS_SKL(dev) return -EINVAL; check since the flag isnt
> > valid anywhere else. 
> The override flag is required for the asymmetrical BSD rings in SKL. But
> it will be reasonable that user-space driver should have an opportunity
> to determine which ring is to dispatch the BSD GPU command even though
> the two rings are symmetrical, like BDW.
> I will send out a new version of the patch to add more comments.

Well, I need a real user for this and it needs to be opensource. Given
that the real user on bdw currently is closed source this is a bit tricky
and one of these things to send Dave Airlie into ballistic modes. So I
don't want to try even.

> > Also you must add code to reject these flags if
> > userspace selects a ring other than bsd.
> "if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_BSD) " condition
> checks already make sure that userspace would not select a ring other
> than bsd.

Yeah, but userspace could submit e.g. EXEC_BLITTER | EXEC_BSD_RING1 which
doesn't make sense and must be rejected.

> > And all these new -EINVAL cases need new subtests to validate them in
> > gem_exec_params.c.
> > 
> > And I might have missed some case, ioctl validation is hard ;-) So please
> > double-check that really no insane combination that userspace might try to
> > abuse is caught and has a testcase in gem_exec_params.
> > 
> > /endquote
> > 
> > The testcase also doesn't check for these nasty condiditions (it would
> > fail with the current patch).
> Could you please give examples for "nasty conditions", I will add them.

Two things essentially:
- all flag combinations that don't make sense _must_ be rejected with
  -EINVAL.
- you must have an igt testcase for each such case

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Infrastructure for supporting different GGTT views per object

[Daniel Vetter]

On Tue, Dec 09, 2014 at 03:23:35PM +, Michel Thierry wrote:
> On 12/5/2014 12:11 PM, Tvrtko Ursulin wrote:
> >From: Tvrtko Ursulin 
> >
> >Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
> >to map objects into the same address space multiple times.
> >
> >Added a GGTT view concept and linked it with the VMA to distinguish between
> >multiple instances per address space.
> >
> >New objects and GEM functions which do not take this new view as a parameter
> >assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the
> >previous behaviour.
> >
> >This now means that objects can have multiple VMA entries so the code which
> >assumed there will only be one also had to be modified.
> >
> >Alternative GGTT views are supposed to borrow DMA addresses from obj->pages
> >which is DMA mapped on first VMA instantiation and unmapped on the last one
> >going away.
> >
> >v2:
> > * Removed per view special casing in i915_gem_ggtt_prepare /
> >   finish_object in favour of creating and destroying DMA mappings
> >   on first VMA instantiation and last VMA destruction. (Daniel Vetter)
> > * Simplified i915_vma_unbind which does not need to count the GGTT 
> > views.
> >   (Daniel Vetter)
> > * Also moved obj->map_and_fenceable reset under the same check.
> > * Checkpatch cleanups.
> >
> >v3:
> > * Only retire objects once the last VMA is unbound.
> >
> >v4:
> > * Keep scatter-gather table for alternative views persistent for the
> >   lifetime of the VMA.
> > * Propagate binding errors to callers and handle appropriately.
> >
> >For: VIZ-4544
> >Signed-off-by: Tvrtko Ursulin 
> >Cc: Daniel Vetter 
> >---
> >  drivers/gpu/drm/i915/i915_debugfs.c|   5 +-
> >  drivers/gpu/drm/i915/i915_drv.h|  46 +++--
> >  drivers/gpu/drm/i915/i915_gem.c| 101 
> > ++---
> >  drivers/gpu/drm/i915/i915_gem_context.c|  11 +++-
> >  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   9 ++-
> >  drivers/gpu/drm/i915/i915_gem_gtt.c|  70 +---
> >  drivers/gpu/drm/i915/i915_gem_gtt.h|  22 +++
> >  drivers/gpu/drm/i915/i915_gpu_error.c  |   8 +--
> >  8 files changed, 206 insertions(+), 66 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> >b/drivers/gpu/drm/i915/i915_debugfs.c
> >index 6c16939..bd08289 100644
> >--- a/drivers/gpu/drm/i915/i915_debugfs.c
> >+++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >@@ -152,8 +152,9 @@ describe_obj(struct seq_file *m, struct 
> >drm_i915_gem_object *obj)
> > seq_puts(m, " (pp");
> > else
> > seq_puts(m, " (g");
> >-seq_printf(m, "gtt offset: %08lx, size: %08lx)",
> >-   vma->node.start, vma->node.size);
> >+seq_printf(m, "gtt offset: %08lx, size: %08lx, type: %u)",
> >+   vma->node.start, vma->node.size,
> >+   vma->ggtt_view.type);
> > }
> > if (obj->stolen)
> > seq_printf(m, " (stolen: %08lx)", obj->stolen->start);
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index 049482f..b2f6f7d 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -2514,10 +2514,23 @@ void i915_gem_vma_destroy(struct i915_vma *vma);
> >  #define PIN_GLOBAL 0x4
> >  #define PIN_OFFSET_BIAS 0x8
> >  #define PIN_OFFSET_MASK (~4095)
> >+int __must_check i915_gem_object_pin_view(struct drm_i915_gem_object *obj,
> >+  struct i915_address_space *vm,
> >+  uint32_t alignment,
> >+  uint64_t flags,
> >+  const struct i915_ggtt_view *view);
> >+static inline
> >  int __must_check i915_gem_object_pin(struct drm_i915_gem_object *obj,
> >  struct i915_address_space *vm,
> >  uint32_t alignment,
> >- uint64_t flags);
> >+ uint64_t flags)
> >+{
> >+return i915_gem_object_pin_view(obj, vm, alignment, flags,
> >+&i915_ggtt_view_normal);
> >+}
> >+
> >+int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level,
> >+  u32 flags);
> >  int __must_check i915_vma_unbind(struct i915_vma *vma);
> >  int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
> >  void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
> >@@ -2679,18 +2692,43 @@ struct dma_buf *i915_gem_prime_export(struct 
> >drm_device *dev,
> >  void i915_gem_restore_fences(struct drm_device *dev);
> >+unsigned long i915_gem_obj_offset_view(struct drm_i915_gem_object *o,
> >+   struct i915_address_space *vm,
> >+   enum i915_ggtt_view_typ

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Add WaHdcDisableFetchWhenMasked

[Daniel Vetter]

On Tue, Dec 09, 2014 at 01:37:21PM +, Michel Thierry wrote:
> On 12/5/2014 2:41 PM, Daniel Vetter wrote:
> >On Thu, Dec 04, 2014 at 05:25:56PM +0200, Ville Syrjälä wrote:
> >>On Thu, Dec 04, 2014 at 03:07:52PM +, Michel Thierry wrote:
> >>>We already have it for chv, but was missing for bdw.
> >>>
> >>>Signed-off-by: Michel Thierry 
> >>>---
> >>>  drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
> >>>  1 file changed, 2 insertions(+)
> >>>
> >>Reviewed-by: Ville Syrjälä 
> >Queued for -next, thanks for the patch.
> >-Daniel
> 
> Hi Daniel,
> 
> Thanks for merging the patch, but you picked v1.
> I sent an updated version adding the missing wa name in that same register,
> as Ville suggested
> (1417707632-8656-1-git-send-email-michel.thie...@intel.com).

Oops sorry. Unfortunately that is already in the frozen part of dinq
history, so can't exchange. Can you please resubmit a new patch with just
the missing bits (and Ville's r-b included)?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: DSI sequence related changes for DSI Port C

[Daniel Vetter]

On Tue, Dec 09, 2014 at 12:30:49PM +0200, Jani Nikula wrote:
> On Tue, 09 Dec 2014, "Singh, Gaurav K"  wrote:
> > On 12/7/2014 4:13 PM, Gaurav K Singh wrote:
> >> For DSI Port A & C, the seq_port value has been set to 0 now in VBT
> >> Now  the sequence of DSI single link on Port A and Port C will based
> >> on the DVO port from VBT block 2.
> >>
> >> Signed-off-by: Gaurav K Singh 
> >> ---
> >>   drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |9 -
> >>   1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
> >> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> index f8c2269..e7e2e52 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> >> @@ -110,7 +110,14 @@ static u8 *mipi_exec_send_packet(struct intel_dsi 
> >> *intel_dsi, u8 *data)
> >>vc = (byte >> MIPI_VIRTUAL_CHANNEL_SHIFT) & 0x3;
> >>seq_port = (byte >> MIPI_PORT_SHIFT) & 0x3;
> >>   
> >> -  port = intel_dsi_seq_port_to_port(seq_port);
> >> +  /* For DSI Port A & C, the seq_port value has been set to 0 now in VBT
> >> +   * Now  the sequence of DSI single link on Port A and Port C will based
> >> +   * on the DVO port from VBT block 2.
> >> +   */
> >> +  if (intel_dsi->ports == (1 << PORT_C))
> >> +  port = PORT_C;
> >> +  else
> >> +  port = intel_dsi_seq_port_to_port(seq_port);
> >>/* LP or HS mode */
> >>intel_dsi->hs = mode;
> >>   
> >
> > Jani,
> >
> > Need your reviewed-by on this patch too.
> 
> Okay, I was confused because there were actually five patches in this
> four patch series! ;)
> 
> The *code* is
> 
> Reviewed-by: Jani Nikula 
> 
> because I understand it, but frankly both the commit message and the
> comment confuse me more.

Hm, do you have suggestions for a better commit message? Should we just
drop the comment. I agree that the talk about VBT is really confusing and
smells like leftovers from other stuff.

I'll wait with this one until this is resolved. Accurate and clear commit
messages are important.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: add component support

[Daniel Vetter]

On Tue, Dec 09, 2014 at 12:33:21PM +0200, Jani Nikula wrote:
> On Tue, 09 Dec 2014, Daniel Vetter  wrote:
> > On Tue, Dec 09, 2014 at 11:41:17AM +0200, Imre Deak wrote:
> >> Register a component to be used to interface with the snd_hda_intel
> >> driver. This is meant to replace the same interface that is currently
> >> based on module symbol lookup.
> >> 
> >> v2:
> >> - change roles between the hda and i915 components (Daniel)
> >> - add the implementation to a new file (Jani)
> >
> > I disagree with the name here - intel_component.c is not really
> > descriptive since it's not really. Imo it makes much more sense to put
> > this into intel_audio.c. After all it's all about how we interact with the
> > audio side, which will be even more obvious once we have a dedicated
> > subdevice for this.
> 
> If we keep this component audio specific, then I guess I agree
> intel_audio.c is the better place for it. But that means anything else
> (like possibly pmic driver interaction) will need to have a component of
> its own.

I guess it depends upon how we'll structure it, but if i915 needs to
access pmic then pmic needs to expose a new platform dev/component and
i915 is a master. This won't interfere I think since it's something from
the i915 device that we expose for the audio driver.

So high-level summary of component:
- master: the main part which owns the userspace/logical device (e.g.
  drm_device, snd_dev, ...)
- component: various bits&pieces all over needed for a master, but not
  part of the main device. In DT-land that's everything since the main
  device is just a fake DT node to bundle everything up with no realation
  to real hw. In acpi we'll likely always have some real acpi or pci
  device as master.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/5] ALSA: hda: add component support

[Daniel Vetter]

On Tue, Dec 09, 2014 at 06:30:40PM +0100, Takashi Iwai wrote:
> At Tue, 9 Dec 2014 11:19:34 +0100,
> Daniel Vetter wrote:
> > 
> > On Tue, Dec 09, 2014 at 11:41:18AM +0200, Imre Deak wrote:
> > > Register a component master to be used to interface with the i915
> > > driver. This is meant to replace the current interface which is based on
> > > module symbol lookups.
> > > 
> > > Note that currently we keep the existing behavior and pin the i915
> > > module while the hda driver is loaded. Using the component interface
> > > allows us to remove this dependency once support for dynamically
> > > enabling / disabling the HDMI functionality is added to the driver.
> > > 
> > > v2:
> > > - change roles between the hda and i915 components (Daniel)
> > > 
> > > Signed-off-by: Imre Deak 
> > 
> > Ok, I think this is a good foundation to build on and later on add more
> > pieces to fix suspend/resume and similar.
> > 
> > But we also need to discuss how to merge this. My proposal is that I do a
> > special topic branch with just the patches in this series and then pull
> > that into drm-intel-next and send a pull request for it to Takashi for
> > sound-next, too. That way we don't have any depencies between drm and
> > sound for the 3.20 merge window.
> > 
> > Testing by intel QA is also solved this way since sound-next is already
> > pulled into drm-intel-nightly. And both gfx and sound QA use that branch.
> > 
> > Takashi/Dave, does this sound good?
> 
> Yes, this sounds good.  Maybe it'd be good to base the branch on
> 3.19-rc1 so that all changes are covered?

Guess that depends when the patches are ready for merging and whether
there's conflicts. I have sound-next in my integration tree so will
noticed and can act accordingly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: DSI sequence related changes for DSI Port C

[Singh, Gaurav K]

On 12/10/2014 2:50 PM, Daniel Vetter wrote:

On Tue, Dec 09, 2014 at 12:30:49PM +0200, Jani Nikula wrote:

On Tue, 09 Dec 2014, "Singh, Gaurav K"  wrote:

On 12/7/2014 4:13 PM, Gaurav K Singh wrote:

For DSI Port A & C, the seq_port value has been set to 0 now in VBT
Now  the sequence of DSI single link on Port A and Port C will based
on the DVO port from VBT block 2.

Signed-off-by: Gaurav K Singh 
---
   drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |9 -
   1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f8c2269..e7e2e52 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -110,7 +110,14 @@ static u8 *mipi_exec_send_packet(struct intel_dsi 
*intel_dsi, u8 *data)
vc = (byte >> MIPI_VIRTUAL_CHANNEL_SHIFT) & 0x3;
seq_port = (byte >> MIPI_PORT_SHIFT) & 0x3;
   
-	port = intel_dsi_seq_port_to_port(seq_port);

+   /* For DSI Port A & C, the seq_port value has been set to 0 now in VBT
+* Now  the sequence of DSI single link on Port A and Port C will based
+* on the DVO port from VBT block 2.
+*/
+   if (intel_dsi->ports == (1 << PORT_C))
+   port = PORT_C;
+   else
+   port = intel_dsi_seq_port_to_port(seq_port);
/* LP or HS mode */
intel_dsi->hs = mode;
   

Jani,

Need your reviewed-by on this patch too.

Okay, I was confused because there were actually five patches in this
four patch series! ;)

The *code* is

Reviewed-by: Jani Nikula 

because I understand it, but frankly both the commit message and the
comment confuse me more.

Hm, do you have suggestions for a better commit message? Should we just
drop the comment. I agree that the talk about VBT is really confusing and
smells like leftovers from other stuff.

I'll wait with this one until this is resolved. Accurate and clear commit
messages are important.
-Daniel

Jani,

How is the below commit message?

From now on for both DSI Ports A & C, the seq_port value has been set to 0.
seq_port value is parsed from Sequence block#53 of VBT.So, for packets that 
needs to be
read/write for DSI single link on Port A and Port C will based on the DVO port 
from VBT block 2.

With regards,
Gaurav
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/2] lib/igt_debugfs: Throw away the two first CRCs

[Daniel Vetter]

On Tue, Dec 09, 2014 at 05:25:16PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> On CHV we sometimes see not just one but two bad CRCs. No real idea
> what would cause that, but let's just throw away the second CRC as
> well to gain some stability for the tests.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  lib/igt_debugfs.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
> index 0b098ee..b44333e 100644
> --- a/lib/igt_debugfs.c
> +++ b/lib/igt_debugfs.c
> @@ -425,8 +425,11 @@ void igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc)
>   /*
>* For some no yet identified reason, the first CRC is bonkers. So
>* let's just wait for the next vblank and read out the buggy result.
> +  *
> +  * On CHV sometimes the second CRC is bonkers as well, so don't trust
> +  * that one either.
>*/
> - igt_pipe_crc_get_crcs(pipe_crc, 1, &crcs);
> + igt_pipe_crc_get_crcs(pipe_crc, 2, &crcs);

I wonder a bit whether we shouldn't push these vblank waits into the
kernel, maybe with some comments.

Wrt chv: Is this only on DP outputs? could be that the scrambler takes 2
vblanks (1 to set the bit, 1 to actually act on it) to go into the new
fancy mode.
-Daniel

>   free(crcs);
>  }
>  
> -- 
> 2.0.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add headers to the various render state

[Daniel Vetter]

On Tue, Dec 09, 2014 at 05:23:22PM +, Damien Lespiau wrote:
> intel-gpu-tools now generates the render state with license headers and
> the version of i-g-t that generated the files.
> 
> A similar patch was previously sent but wasn't actually generated with
> the make target so was lacking the i-g-t revision. So here another
> version before we totally forget about this.
> 
> Cc: Armin Reese 
> Cc: Mika Kuoppala 
> Signed-off-by: Damien Lespiau 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_renderstate_gen6.c | 25 +
>  drivers/gpu/drm/i915/intel_renderstate_gen7.c | 25 +
>  drivers/gpu/drm/i915/intel_renderstate_gen8.c | 25 +
>  drivers/gpu/drm/i915/intel_renderstate_gen9.c | 25 +
>  4 files changed, 100 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen6.c 
> b/drivers/gpu/drm/i915/intel_renderstate_gen6.c
> index 56c1429..11c8e7b 100644
> --- a/drivers/gpu/drm/i915/intel_renderstate_gen6.c
> +++ b/drivers/gpu/drm/i915/intel_renderstate_gen6.c
> @@ -1,3 +1,28 @@
> +/*
> + * Copyright © 2014 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.
> + *
> + * Generated by: intel-gpu-tools-1.8-220-g01153e7
> + */
> +
>  #include "intel_renderstate.h"
>  
>  static const u32 gen6_null_state_relocs[] = {
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen7.c 
> b/drivers/gpu/drm/i915/intel_renderstate_gen7.c
> index 419e35a..6551806 100644
> --- a/drivers/gpu/drm/i915/intel_renderstate_gen7.c
> +++ b/drivers/gpu/drm/i915/intel_renderstate_gen7.c
> @@ -1,3 +1,28 @@
> +/*
> + * Copyright © 2014 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.
> + *
> + * Generated by: intel-gpu-tools-1.8-220-g01153e7
> + */
> +
>  #include "intel_renderstate.h"
>  
>  static const u32 gen7_null_state_relocs[] = {
> diff --git a/drivers/gpu/drm/i915/intel_renderstate_gen8.c 
> b/drivers/gpu/drm/i915/intel_renderstate_gen8.c
> index 78011d7..95288a3 100644
> --- a/drivers/gpu/drm/i915/intel_renderstate_gen8.c
> +++ b/drivers/gpu/drm/i915/intel_renderstate_gen8.c
> @@ -1,3 +1,28 @@
> +/*
> + * Copyright © 2014 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 pe

Re: [Intel-gfx] [PATCH v3] drm/i915/bdw: Fix the write setting up the WIZ hashing mode

[Jani Nikula]

On Mon, 08 Dec 2014, Damien Lespiau  wrote:
> I was playing with clang and oh surprise! a warning trigerred by
> -Wshift-overflow (gcc doesn't have this one):
>
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
>   GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
>
> drivers/gpu/drm/i915/intel_ringbuffer.c:786:2: warning: signed shift 
> result
>   (0x2800200) requires 43 bits to represent, but 'int' only has 32 
> bits
>   [-Wshift-overflow]
> WA_SET_BIT_MASKED(GEN7_GT_MODE,
> ^~~
> drivers/gpu/drm/i915/intel_ringbuffer.c:737:15: note: expanded from macro
>   'WA_SET_BIT_MASKED'
> WA_REG(addr, _MASKED_BIT_ENABLE(mask), (mask) & 0x)
>
> Turned out GEN6_WIZ_HASHING_MASK was already shifted by 16, and we were
> trying to shift it a bit more.
>
> The other thing is that it's not the usual case of setting WA bits here, we
> need to have separate mask and value.
>
> To fix this, I've introduced a new _MASKED_FIELD() macro that takes both the
> (unshifted) mask and the desired value and the rest of the patch ripples
> through from it.
>
> This bug was introduced when reworking the WA emission in:
>
>   Commit 7225342ab501befdb64bcec76ded41f5897c0855
>   Author: Mika Kuoppala 
>   Date:   Tue Oct 7 17:21:26 2014 +0300
>
>   drm/i915: Build workaround list in ring initialization
>
> v2: Invert the order of the mask and value arguments (Daniel Vetter)
> Rewrite _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE() with
> _MASKED_FIELD() (Jani Nikula)
> Make sure we only evaluate 'a' once in _MASKED_BIT_ENABLE() (Dave Gordon)
> Add check to ensure the value is within the mask boundaries (Chris Wilson)
>
> v3: Ensure the the value and mask are 16 bits (Dave Gordon)
>
> Cc: Mika Kuoppala 
> Cc: Arun Siluvery 
> Signed-off-by: Damien Lespiau 

Pushed to drm-intel-next-fixes, replacing the old version. Thanks for
the patch.

Now the question is, do we want [1] for 3.19 or 3.20?

BR,
Jani.


http://mid.gmane.org/1418060138-5004-1-git-send-email-damien.lesp...@intel.com


> ---
>  drivers/gpu/drm/i915/i915_reg.h | 17 ++---
>  drivers/gpu/drm/i915/intel_pm.c |  6 +++---
>  drivers/gpu/drm/i915/intel_ringbuffer.c |  8 ++--
>  3 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index dc03fac..454a3a3 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -34,8 +34,19 @@
>  #define _PORT3(port, a, b, c) ((port) == PORT_A ? (a) : \
>  (port) == PORT_B ? (b) : (c))
>  
> -#define _MASKED_BIT_ENABLE(a) (((a) << 16) | (a))
> -#define _MASKED_BIT_DISABLE(a) ((a) << 16)
> +#define _MASKED_FIELD(mask, value) ({
>\
> + if (__builtin_constant_p(mask))\
> + BUILD_BUG_ON_MSG(((mask) & 0x), "Incorrect mask"); \
> + if (__builtin_constant_p(value))   \
> + BUILD_BUG_ON_MSG((value) & 0x, "Incorrect value"); \
> + if (__builtin_constant_p(mask) && __builtin_constant_p(value)) \
> + BUILD_BUG_ON_MSG((value) & ~(mask),\
> +  "Incorrect value for mask");  \
> + (mask) << 16 | (value); })
> +#define _MASKED_BIT_ENABLE(a)({ typeof(a) _a = (a); 
> _MASKED_FIELD(_a, _a); })
> +#define _MASKED_BIT_DISABLE(a)   (_MASKED_FIELD((a), 0))
> +
> +
>  
>  /* PCI config space */
>  
> @@ -1284,7 +1295,7 @@ enum punit_power_well {
>  #define   GEN6_WIZ_HASHING_8x8   
> GEN6_WIZ_HASHING(0, 0)
>  #define   GEN6_WIZ_HASHING_8x4   
> GEN6_WIZ_HASHING(0, 1)
>  #define   GEN6_WIZ_HASHING_16x4  
> GEN6_WIZ_HASHING(1, 0)
> -#define   GEN6_WIZ_HASHING_MASK  
> (GEN6_WIZ_HASHING(1, 1) << 16)
> +#define   GEN6_WIZ_HASHING_MASK  
> GEN6_WIZ_HASHING(1, 1)
>  #define   GEN6_TD_FOUR_ROW_DISPATCH_DISABLE  (1 << 5)
>  
>  #define GFX_MODE 0x02520
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 78911e2..0f2febd 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6389,7 +6389,7 @@ static void gen6_init_clock_gating(struct drm_device 
> *dev)
>* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
>*/
>   I915_WRITE(GEN6_GT_MODE,
> -GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
> +_MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
>  
>   ilk_init_lp_watermarks(dev);
>  
> @@ -6587,7 +6587,7 @@ static void haswell_init_clock_gating(struct drm_device 
> *dev)
>* to keep in mind (see 3DSTATE_PS and 3DSTATE_WM).
>*/
>   I915_WRITE(GEN7_G

[Intel-gfx] [PATCH] drm/i915/bdw: Add WaForceEnableNonCoherent label

[Michel Thierry]

We already implement this workaround, but it was missing its name.

Reviewed-by: Ville Syrjälä 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 91ddcd1..5b51a43 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -756,6 +756,7 @@ static int bdw_init_workarounds(struct intel_engine_cs 
*ring)
 * workaround for for a possible hang in the unlikely event a TLB
 * invalidation occurs during a PSD flush.
 */
+   /* WaForceEnableNonCoherent:bdw */
/* WaHdcDisableFetchWhenMasked:bdw */
/* WaDisableFenceDestinationToSLM:bdw (GT3 pre-production) */
WA_SET_BIT_MASKED(HDC_CHICKEN0,
-- 
2.1.1

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

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Add WaHdcDisableFetchWhenMasked

[Michel Thierry]

On 12/10/2014 9:18 AM, Daniel Vetter wrote:

On Tue, Dec 09, 2014 at 01:37:21PM +, Michel Thierry wrote:

On 12/5/2014 2:41 PM, Daniel Vetter wrote:

On Thu, Dec 04, 2014 at 05:25:56PM +0200, Ville Syrjälä wrote:

On Thu, Dec 04, 2014 at 03:07:52PM +, Michel Thierry wrote:

We already have it for chv, but was missing for bdw.

Signed-off-by: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
  1 file changed, 2 insertions(+)


Reviewed-by: Ville Syrjälä 

Queued for -next, thanks for the patch.
-Daniel

Hi Daniel,

Thanks for merging the patch, but you picked v1.
I sent an updated version adding the missing wa name in that same register,
as Ville suggested
(1417707632-8656-1-git-send-email-michel.thie...@intel.com).

Oops sorry. Unfortunately that is already in the frozen part of dinq
history, so can't exchange. Can you please resubmit a new patch with just
the missing bits (and Ville's r-b included)?

Thanks, Daniel


Sure, I just sent it.

Thanks,




smime.p7s
Description: S/MIME Cryptographic Signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Fix CRC support for DP port D on CHV

[Daniel Vetter]

On Tue, Dec 09, 2014 at 09:28:29PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Add the missing CRC control register value for DP port D on CHV.
> Untested as I don't have a CHV machine with DP on port D.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d74b62d..5620b8f 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3100,6 +3100,10 @@ static int vlv_pipe_crc_ctl_reg(struct drm_device *dev,
>   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_VLV;
>   need_stable_symbols = true;
>   break;
> + case INTEL_PIPE_CRC_SOURCE_DP_D:

We need to keep rejecting DP D on vlv. I've added a check for that while
merging this patch.
-Daniel

> + *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_D_VLV;
> + need_stable_symbols = true;
> + break;
>   case INTEL_PIPE_CRC_SOURCE_NONE:
>   *val = 0;
>   break;
> -- 
> 2.0.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Make i915_pipe_crc_read() oops proof

[Daniel Vetter]

On Tue, Dec 09, 2014 at 09:28:32PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Currently i915_pipe_crc_read() will drop pipe_crc->lock for the entire
> duration of the copy_to_user() loop, which means it'll access
> pipe_crc->entries without any protection. If another thread sneaks in
> and frees pipe_crc->entries the code will oops.
> 
> Reorganize the code to hold the lock around everything except
> copy_to_user(). After the copy the lock is reacquired and the the number
> of available entries is rechecked.
> 
> Since this is a debug feature simplify the error handling a bit by
> consuming the crc entry even if copy_to_user() would fail.
> 
> Signed-off-by: Ville Syrjälä 

While you go to all this trouble with making the debugfs interface safe
against stupid userspace: set_source has a potential leak when ->entries
is already allocated when we set it. An unconditional
kfree(pipe_crc->entries); before should be all we need since kfree can
handle this. I'll smash a patch on top.

Entire series merged, thanks.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 39 
> +
>  1 file changed, 22 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d9d5f1f..1c61564 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2858,7 +2858,7 @@ i915_pipe_crc_read(struct file *filep, char __user 
> *user_buf, size_t count,
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[info->pipe];
>   char buf[PIPE_CRC_BUFFER_LEN];
> - int head, tail, n_entries, n;
> + int n_entries;
>   ssize_t bytes_read;
>  
>   /*
> @@ -2890,36 +2890,39 @@ i915_pipe_crc_read(struct file *filep, char __user 
> *user_buf, size_t count,
>   }
>  
>   /* We now have one or more entries to read */
> - head = pipe_crc->head;
> - tail = pipe_crc->tail;
> - n_entries = min((size_t)CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR),
> - count / PIPE_CRC_LINE_LEN);
> - spin_unlock_irq(&pipe_crc->lock);
> + n_entries = count / PIPE_CRC_LINE_LEN;
>  
>   bytes_read = 0;
> - n = 0;
> - do {
> - struct intel_pipe_crc_entry *entry = &pipe_crc->entries[tail];
> + while (n_entries > 0) {
> + struct intel_pipe_crc_entry *entry =
> + &pipe_crc->entries[pipe_crc->tail];
>   int ret;
>  
> + if (CIRC_CNT(pipe_crc->head, pipe_crc->tail,
> +  INTEL_PIPE_CRC_ENTRIES_NR) < 1)
> + break;
> +
> + BUILD_BUG_ON_NOT_POWER_OF_2(INTEL_PIPE_CRC_ENTRIES_NR);
> + pipe_crc->tail = (pipe_crc->tail + 1) & 
> (INTEL_PIPE_CRC_ENTRIES_NR - 1);
> +
>   bytes_read += snprintf(buf, PIPE_CRC_BUFFER_LEN,
>  "%8u %8x %8x %8x %8x %8x\n",
>  entry->frame, entry->crc[0],
>  entry->crc[1], entry->crc[2],
>  entry->crc[3], entry->crc[4]);
>  
> - ret = copy_to_user(user_buf + n * PIPE_CRC_LINE_LEN,
> -buf, PIPE_CRC_LINE_LEN);
> + spin_unlock_irq(&pipe_crc->lock);
> +
> + ret = copy_to_user(user_buf, buf, PIPE_CRC_LINE_LEN);
>   if (ret == PIPE_CRC_LINE_LEN)
>   return -EFAULT;
>  
> - BUILD_BUG_ON_NOT_POWER_OF_2(INTEL_PIPE_CRC_ENTRIES_NR);
> - tail = (tail + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1);
> - n++;
> - } while (--n_entries);
> + user_buf += PIPE_CRC_LINE_LEN;
> + n_entries--;
> +
> + spin_lock_irq(&pipe_crc->lock);
> + }
>  
> - spin_lock_irq(&pipe_crc->lock);
> - pipe_crc->tail = tail;
>   spin_unlock_irq(&pipe_crc->lock);
>  
>   return bytes_read;
> @@ -3456,6 +3459,8 @@ static int pipe_crc_set_source(struct drm_device *dev, 
> enum pipe pipe,
>   spin_lock_irq(&pipe_crc->lock);
>   entries = pipe_crc->entries;
>   pipe_crc->entries = NULL;
> + pipe_crc->head = 0;
> + pipe_crc->tail = 0;
>   spin_unlock_irq(&pipe_crc->lock);
>  
>   kfree(entries);
> -- 
> 2.0.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Protect against leaks in pipe_crc_set_source

[Daniel Vetter]

Stupid userspace (there is no evil userspace in debugfs by assumption)
might provoke a leak since we allocate the new array without holding
any locks. Drop in an unconditional kfree to deal with this - kfree
can handle NULL.

Cc: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 72bb5aef9590..923e7575bb53 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3433,6 +3433,7 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
hsw_disable_ips(crtc);
 
spin_lock_irq(&pipe_crc->lock);
+   kfree(pipe_crc->entries);
pipe_crc->entries = entries;
pipe_crc->head = 0;
pipe_crc->tail = 0;
-- 
2.1.1

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

Re: [Intel-gfx] [PATCH 1/7] drm/plane-helper: Test for plane disable earlier

[Daniel Vetter]

On Tue, Dec 09, 2014 at 11:53:37AM -0800, Matt Roper wrote:
> drm_plane_helper_check_update() currently uses crtc before testing whether
> we're disabling the plane (fb == NULL).  Move the fb test before the first 
> crtc
> usage so that crtc == NULL doesn't have to be handled by the caller.
> 
> Signed-off-by: Matt Roper 

Makes sense, but can you please resubmit with dri-devel cced?

Thanks, Daniel

> ---
>  drivers/gpu/drm/drm_plane_helper.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index ae61fb2..f24c4cf 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -142,6 +142,17 @@ int drm_plane_helper_check_update(struct drm_plane 
> *plane,
>  {
>   int hscale, vscale;
>  
> + if (!fb) {
> + *visible = false;
> + return 0;
> + }
> +
> + /* crtc should only be NULL when disabling (i.e., !fb) */
> + if (WARN_ON(!crtc)) {
> + *visible = false;
> + return 0;
> + }
> +
>   if (!crtc->enabled && !can_update_disabled) {
>   DRM_DEBUG_KMS("Cannot update plane of a disabled CRTC.\n");
>   return -EINVAL;
> @@ -155,11 +166,6 @@ int drm_plane_helper_check_update(struct drm_plane 
> *plane,
>   return -ERANGE;
>   }
>  
> - if (!fb) {
> - *visible = false;
> - return 0;
> - }
> -
>   *visible = drm_rect_clip_scaled(src, dest, clip, hscale, vscale);
>   if (!*visible)
>   /*
> -- 
> 1.8.5.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Make i915_pipe_crc_read() oops proof

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1-6  364/366  359/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt_kms_flip_rcs-wf_vblank-vs-dpms-interruptible  PASS(6, M26)  
NSPT(1, M26)
 ILK  igt_kms_flip_blocking-absolute-wf_vblank-interruptible  DMESG_WARN(1, 
M26)PASS(5, M26)  DMESG_WARN(1, M26)
*ILK  igt_kms_flip_flip-vs-panning  PASS(5, M26)  DMESG_WARN(1, M26)
*ILK  igt_kms_flip_rcs-flip-vs-dpms  PASS(4, M26)  DMESG_WARN(1, M26)
*ILK  igt_kms_flip_rcs-flip-vs-modeset  PASS(4, M26)  NSPT(1, M26)
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(2, M26)PASS(13, M26M37)   
   PASS(1, M26)
*ILK  igt_kms_flip_wf_vblank-vs-modeset-interruptible  PASS(4, M26)  
DMESG_WARN(1, M26)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 6/9] lib: s/IGT_DEBUG_INTERACTIVE/--interactive-debug=var

[Daniel Vetter]

On Tue, Dec 09, 2014 at 09:01:54PM -0500, Rodrigo Vivi wrote:
> Use cmdline variable for interactive debug instead of env var.
> 
> Signed-off-by: Rodrigo Vivi 

Looks nice, two small comments below.

> ---
>  lib/igt_aux.c  | 20 ++--
>  lib/igt_aux.h  |  2 +-
>  lib/igt_core.c |  6 ++
>  lib/igt_core.h |  2 ++
>  4 files changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index 49d1ec4..ff668d4 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -372,32 +372,32 @@ void igt_drop_root(void)
>  
>  /**
>   * igt_debug_wait_for_keypress:
> - * @key: env var lookup to to enable this wait
> + * @var: var lookup to to enable this wait
>   *
>   * Waits for a key press when run interactively and when the corresponding 
> debug
> - * key is set in the IGT_DEBUG_INTERACTIVE environment variable. Multiple 
> keys
> + * var is set in the --interactive-debug= variable. Multiple keys
>   * can be specified as a comma-separated list or alternatively "all" if a 
> wait
> - * should happen for all keys.  When not connected to a terminal the 
> environment
> - * setting is ignored and execution immediately continues.
> + * should happen for all cases.
> + *
> + * When not connected to a terminal interactive_debug is ignored
> + * and execution immediately continues.
>   *
>   * This is useful for display tests where under certain situation manual
>   * inspection of the display is useful. Or when running a testcase in the
>   * background.
>   */
> -void igt_debug_wait_for_keypress(const char *key)
> +void igt_debug_wait_for_keypress(const char *var)
>  {
>   struct termios oldt, newt;
> - const char *env;
>  
>   if (!isatty(STDIN_FILENO))
>   return;
>  
> - env = getenv("IGT_DEBUG_INTERACTIVE");
> -
> - if (!env)
> + if (!igt_interactive_debug)
>   return;
>  
> - if (!strstr(env, key) && !strstr(env, "all"))
> + if (!strstr(igt_interactive_debug, var) &&
> + !strstr(igt_interactive_debug, "all"))
>   return;
>  
>   igt_info("Press any key to continue ...\n");
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index 63e1b06..59022cd 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -60,7 +60,7 @@ void igt_system_suspend_autoresume(void);
>  /* dropping priviledges */
>  void igt_drop_root(void);
>  
> -void igt_debug_wait_for_keypress(const char *key);
> +void igt_debug_wait_for_keypress(const char *var);
>  
>  enum igt_runtime_pm_status {
>   IGT_RUNTIME_PM_STATUS_ACTIVE,
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 13a52a5..461b1d3 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -225,6 +225,7 @@ enum {
>   OPT_RUN_SUBTEST,
>   OPT_DESCRIPTION,
>   OPT_DEBUG,
> + OPT_INTERACTIVE_DEBUG,
>   OPT_HELP = 'h'
>  };
>  
> @@ -391,6 +392,7 @@ static void print_usage(const char *help_str, bool 
> output_on_stderr)
>   fprintf(f, "  --list-subtests\n"
>  "  --run-subtest \n"
>  "  --debug\n"
> +"  --interactive-debug \n"
>  "  --help-description\n"
>  "  --help\n");
>   if (help_str)
> @@ -423,6 +425,7 @@ static int common_init(int argc, char **argv,
>   {"run-subtest", 1, 0, OPT_RUN_SUBTEST},
>   {"help-description", 0, 0, OPT_DESCRIPTION},
>   {"debug", 0, 0, OPT_DEBUG},
> + {"interactive-debug", 1, 0, OPT_INTERACTIVE_DEBUG},
>   {"help", 0, 0, OPT_HELP},
>   {0, 0, 0, 0}
>   };
> @@ -508,6 +511,9 @@ static int common_init(int argc, char **argv,
>   while ((c = getopt_long(argc, argv, short_opts, combined_opts,
>  &option_index)) != -1) {
>   switch(c) {
> + case OPT_INTERACTIVE_DEBUG:
> + igt_interactive_debug = strdup(optarg);;
> + break;

Hm, while we change this to cmdline option I think we should make the
optarg optional and if it's not set, set it to "all".

>   case OPT_DEBUG:
>   igt_log_level = IGT_LOG_DEBUG;
>   break;
> diff --git a/lib/igt_core.h b/lib/igt_core.h
> index a258348..20942e4 100644
> --- a/lib/igt_core.h
> +++ b/lib/igt_core.h
> @@ -511,6 +511,8 @@ bool igt_run_in_simulation(void);
>  
>  void igt_skip_on_simulation(void);
>  
> +const char *igt_interactive_debug;

Can you please add a bit of gtkdoc for this, too, now that it's exported.

Thanks, Daniel

> +
>  /* structured logging */
>  enum igt_log_level {
>   IGT_LOG_DEBUG,
> -- 
> 1.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.f

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Infrastructure for supporting different GGTT views per object

[Tvrtko Ursulin]

On 12/10/2014 09:16 AM, Daniel Vetter wrote:

On Tue, Dec 09, 2014 at 03:23:35PM +, Michel Thierry wrote:

We also need a _vma_view version of i915_gem_obj_bound;
i915_gem_object_ggtt_unpin checks if the obj is ggtt_bound and it could be
that the normal view is gone but a different view is still active (it is
also used in gpu_error and debug_fs, but I don't think it's a problem
there).


Where did you see the need for the new obj_bound variant? Probably best to
reply to the patch newly with just the relevant part quoted.


It is not in the patch but in the i915_gem_object_ggtt_unpin. Which is:

i915_gem_object_ggtt_unpin(struct drm_i915_gem_object *obj)
{
struct i915_vma *vma = i915_gem_obj_to_ggtt(obj);

BUG_ON(!vma);
BUG_ON(vma->pin_count == 0);
BUG_ON(!i915_gem_obj_ggtt_bound(obj));

if (--vma->pin_count == 0)
obj->pin_mappable = false;
}

The concern is the mismatch in semantics between i915_gem_obj_to_ggtt 
and i915_gem_obj_ggtt_bound. Former implies normal VMA while the latter 
hasn't been touched so it returns true on _any_ GGTT bound VMA.


I don't think this BUG_ON can trigger since normal VMA exists by the 
virtue of BUG_ON(!vma), but I do agree that there is a mismatch in 
"documentation" (BUG_ONs). So making i915_gem_obj_ggtt_bound also imply 
a normal view would be correct it seems.


Regards,

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

Re: [Intel-gfx] [PATCH i-g-t 8/9] lib/igt_aux: Extend igt_debug_wait_for_keypres.

[Daniel Vetter]

On Tue, Dec 09, 2014 at 09:01:56PM -0500, Rodrigo Vivi wrote:
> Return key pressed and allow different messages.
> 
> Signed-off-by: Rodrigo Vivi 

Hm, not sure how useful this really is - when the test fails I just hit ^C
and scream ;-)

What kind of use-case do you have in mind which requires such a structured
approach? In case of doubt I prefer my igt helpers to be really simple, so
if you think we really needs this we should add a new fancy version of
wait_for_keypress with the added msg and return code.
-Daniel

> ---
>  lib/igt_aux.c| 9 ++---
>  lib/igt_aux.h| 2 +-
>  lib/igt_kms.c| 3 ++-
>  tests/kms_psr_sink_crc.c | 5 +++--
>  4 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index ff668d4..a6c5ba6 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -386,9 +386,10 @@ void igt_drop_root(void)
>   * inspection of the display is useful. Or when running a testcase in the
>   * background.
>   */
> -void igt_debug_wait_for_keypress(const char *var)
> +char igt_debug_wait_for_keypress(const char *var, const char *msg)
>  {
>   struct termios oldt, newt;
> + char key;
>  
>   if (!isatty(STDIN_FILENO))
>   return;
> @@ -400,14 +401,16 @@ void igt_debug_wait_for_keypress(const char *var)
>   !strstr(igt_interactive_debug, "all"))
>   return;
>  
> - igt_info("Press any key to continue ...\n");
> + igt_info(msg);
>  
>   tcgetattr ( STDIN_FILENO, &oldt );
>   newt = oldt;
>   newt.c_lflag &= ~ICANON;
>   tcsetattr ( STDIN_FILENO, TCSANOW, &newt );
> - getchar();
> + key = getchar();
>   tcsetattr ( STDIN_FILENO, TCSANOW, &oldt );
> +
> + return key;
>  }
>  
>  #define POWER_DIR "/sys/devices/pci:00/:00:02.0/power"
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index 59022cd..158e4c5 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -60,7 +60,7 @@ void igt_system_suspend_autoresume(void);
>  /* dropping priviledges */
>  void igt_drop_root(void);
>  
> -void igt_debug_wait_for_keypress(const char *var);
> +char igt_debug_wait_for_keypress(const char *var, const char *msg);
>  
>  enum igt_runtime_pm_status {
>   IGT_RUNTIME_PM_STATUS_ACTIVE,
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 1387d01..5c7b2c7 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1561,7 +1561,8 @@ static int do_display_commit(igt_display_t *display,
>  
>   LOG_UNINDENT(display);
>  
> - igt_debug_wait_for_keypress("modeset");
> + igt_debug_wait_for_keypress("modeset",
> + "Press any key to continue ...\n");
>  
>   return 0;
>  }
> diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> index e7a2ef4..8103ebb 100644
> --- a/tests/kms_psr_sink_crc.c
> +++ b/tests/kms_psr_sink_crc.c
> @@ -256,7 +256,7 @@ static void get_sink_crc(data_t *data, char *crc) {
>   fclose(file);
>  
>   igt_debug("%s\n", crc);
> - igt_debug_wait_for_keypress("crc");
> + igt_debug_wait_for_keypress("crc", "Press any key to continue ...\n");
>  
>   /* The important value was already taken.
>* Now give a time for human eyes
> @@ -305,7 +305,8 @@ static void assert_or_manual(bool condition, const char 
> *expected)
>   igt_info("Is %s?\n", expected);
>   else
>   igt_debug("%s\n", expected);
> - igt_debug_wait_for_keypress("manual");
> + igt_debug_wait_for_keypress("manual",
> + "Press any key to continue ...\n");
>   igt_assert(igt_interactive_debug || condition);
>  }
>  
> -- 
> 1.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Quietly reject attempts to create non-pagealigned stolen objects

[Daniel Vetter]

On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> This added as a BUG_ON as it considered that no one would ever request
> an unaligned object. However, it turns out that some BIOSes will
> allocate a scanout that is offset from 0 and not aligned to a page
> boundary, and we were passing this through and hitting the BUG_ON during
> boot.
> 
> Quietly reject such a request to reserve the unaligned stolen object and
> let the boot continue, restoring previous behaviour (i.e. no BIOS
> framebuffer preservation).
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883
> Signed-off-by: Chris Wilson 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 5c616ec2c5c8..a3bc0fa07c6c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -646,13 +646,15 @@ i915_gem_object_create_stolen_for_preallocated(struct 
> drm_device *dev,
>   DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, 
> gtt_offset=%x, size=%x\n",
>   stolen_offset, gtt_offset, size);
>  
> - /* KISS and expect everything to be page-aligned */
> - BUG_ON(stolen_offset & 4095);
> - BUG_ON(size & 4095);
> -
>   if (WARN_ON(size == 0))
>   return NULL;
>  
> + /* KISS and expect everything to be GTT page-aligned */
> + if ((stolen_offset | size) & 4095) {

Imo we should stil WARN_ON and fixup up the takeover code to align things
properly ...
-Daniel

> + DRM_DEBUG_KMS("request for unaligned stolen object, denied\n");
> + return NULL;
> + }
> +
>   stolen = kzalloc(sizeof(*stolen), GFP_KERNEL);
>   if (!stolen)
>   return NULL;
> -- 
> 2.1.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Add WaForceEnableNonCoherent label

[Daniel Vetter]

On Wed, Dec 10, 2014 at 09:43:37AM +, Michel Thierry wrote:
> We already implement this workaround, but it was missing its name.
> 
> Reviewed-by: Ville Syrjälä 
> Signed-off-by: Michel Thierry 

Queued for -next, thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 91ddcd1..5b51a43 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -756,6 +756,7 @@ static int bdw_init_workarounds(struct intel_engine_cs 
> *ring)
>* workaround for for a possible hang in the unlikely event a TLB
>* invalidation occurs during a PSD flush.
>*/
> + /* WaForceEnableNonCoherent:bdw */
>   /* WaHdcDisableFetchWhenMasked:bdw */
>   /* WaDisableFenceDestinationToSLM:bdw (GT3 pre-production) */
>   WA_SET_BIT_MASKED(HDC_CHICKEN0,
> -- 
> 2.1.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Updating assorted register and status page definitions

[Daniel Vetter]

On Tue, Dec 09, 2014 at 12:59:06PM +, john.c.harri...@intel.com wrote:
> From: Dave Gordon 
> 
> Added various definitions that will be useful for the scheduler in general and
> pre-emptive context switching in particular.
> 
> Change-Id: Ica805b94160426def51f5d520f5ce51c60864a98
> For: VIZ-1587
> Signed-off-by: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |   30 ++-
>  drivers/gpu/drm/i915/intel_ringbuffer.h |   40 
> +--
>  2 files changed, 67 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 869e5ae..6169720 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -216,6 +216,10 @@
>  #define  MI_GLOBAL_GTT(1<<22)
>  
>  #define MI_NOOP  MI_INSTR(0, 0)
> +#define   MI_NOOP_WRITE_ID   (1<<22)
> +#define   MI_NOOP_ID_MASK((1<<22) - 1)
> +#define   MI_NOOP_MID(id)((id) & MI_NOOP_ID_MASK)
> +#define MI_NOOP_WITH_ID(id)  MI_INSTR(0, MI_NOOP_WRITE_ID|MI_NOOP_MID(id))
>  #define MI_USER_INTERRUPTMI_INSTR(0x02, 0)
>  #define MI_WAIT_FOR_EVENT   MI_INSTR(0x03, 0)
>  #define   MI_WAIT_FOR_OVERLAY_FLIP   (1<<16)
> @@ -233,6 +237,7 @@
>  #define MI_ARB_ON_OFFMI_INSTR(0x08, 0)
>  #define   MI_ARB_ENABLE  (1<<0)
>  #define   MI_ARB_DISABLE (0<<0)
> +#define MI_ARB_CHECK MI_INSTR(0x05, 0)
>  #define MI_BATCH_BUFFER_END  MI_INSTR(0x0a, 0)
>  #define MI_SUSPEND_FLUSH MI_INSTR(0x0b, 0)
>  #define   MI_SUSPEND_FLUSH_EN(1<<0)
> @@ -281,6 +286,8 @@
>  #define   MI_SEMAPHORE_SYNC_INVALID (3<<16)
>  #define   MI_SEMAPHORE_SYNC_MASK(3<<16)
>  #define MI_SET_CONTEXT   MI_INSTR(0x18, 0)
> +#define   MI_CONTEXT_ADDR_MASK   ((~0)<<12)
> +#define   MI_SET_CONTEXT_FLAG_MASK   ((1<<12)-1)
>  #define   MI_MM_SPACE_GTT(1<<8)
>  #define   MI_MM_SPACE_PHYSICAL   (0<<8)
>  #define   MI_SAVE_EXT_STATE_EN   (1<<3)
> @@ -298,6 +305,10 @@
>  #define   MI_USE_GGTT(1 << 22) /* g4x+ */
>  #define MI_STORE_DWORD_INDEX MI_INSTR(0x21, 1)
>  #define   MI_STORE_DWORD_INDEX_SHIFT 2
> +#define MI_STORE_REG_MEM MI_INSTR(0x24, 1)
> +#define   MI_STORE_REG_MEM_GTT   (1 << 22)
> +#define   MI_STORE_REG_MEM_PREDICATE (1 << 21)
> +
>  /* Official intel docs are somewhat sloppy concerning MI_LOAD_REGISTER_IMM:
>   * - Always issue a MI_NOOP _before_ the MI_LOAD_REGISTER_IMM - otherwise hw
>   *   simply ignores the register load under certain conditions.
> @@ -312,7 +323,10 @@
>  #define MI_FLUSH_DW  MI_INSTR(0x26, 1) /* for GEN6 */
>  #define   MI_FLUSH_DW_STORE_INDEX(1<<21)
>  #define   MI_INVALIDATE_TLB  (1<<18)
> +#define   MI_FLUSH_DW_OP_NONE(0<<14)
>  #define   MI_FLUSH_DW_OP_STOREDW (1<<14)
> +#define   MI_FLUSH_DW_OP_RSVD(2<<14)
> +#define   MI_FLUSH_DW_OP_STAMP   (3<<14)
>  #define   MI_FLUSH_DW_OP_MASK(3<<14)
>  #define   MI_FLUSH_DW_NOTIFY (1<<8)
>  #define   MI_INVALIDATE_BSD  (1<<7)
> @@ -1119,6 +1133,19 @@ enum punit_power_well {
>  #define GEN6_VERSYNC (RING_SYNC_1(VEBOX_RING_BASE))
>  #define GEN6_VEVSYNC (RING_SYNC_2(VEBOX_RING_BASE))
>  #define GEN6_NOSYNC 0
> +
> +/*
> + * Premption-related registers
> + */
> +#define RING_UHPTR(base) ((base)+0x134)
> +#define   UHPTR_GFX_ADDR_ALIGN   (0x7)
> +#define   UHPTR_VALID(0x1)
> +#define RING_PREEMPT_ADDR0x0214c
> +#define   PREEMPT_BATCH_LEVEL_MASK   (0x3)
> +#define BB_PREEMPT_ADDR  0x02148
> +#define SBB_PREEMPT_ADDR 0x0213c
> +#define RS_PREEMPT_STATUS0x0215c
> +
>  #define RING_MAX_IDLE(base)  ((base)+0x54)
>  #define RING_HWS_PGA(base)   ((base)+0x80)
>  #define RING_HWS_PGA_GEN6(base)  ((base)+0x2080)
> @@ -5917,7 +5944,8 @@ enum punit_power_well {
>  #define  VLV_SPAREG2H0xA194
>  
>  #define  GTFIFODBG   0x12
> -#defineGT_FIFO_SBDROPERR (1<<6)
> +#defineGT_FIFO_CPU_ERROR_MASK0xf
> +#defineGT_FIFO_SDDROPERR (1<<6)
>  #defineGT_FIFO_BLOBDROPERR   (1<<5)
>  #defineGT_FIFO_SB_READ_ABORTERR  (1<<4)
>  #defineGT_FIFO_DROPERR   (1<<3)
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 2e0fa7b..f15fc46 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -47,6 +47,12 @@ struct  intel_hw_status_page {
>  #define I915_READ_MODE(ring) I915_READ(RING_MI_MODE((ring)->mmio_base))
>  #define I915_WRITE_MODE(ring, val) 
> I915_WRITE(RING_MI_MODE((ring)->mmio_base), val)
>  
> +#define I915_READ_UHPTR(ring) \
> + I915_READ(RING_UHPTR((ring)->mmio_base))

Re: [Intel-gfx] [PATCH 04/10] drm/i915: FIFO space query code refactor

[Daniel Vetter]

On Tue, Dec 09, 2014 at 12:59:07PM +, john.c.harri...@intel.com wrote:
> From: Dave Gordon 
> 
> When querying the GTFIFOCTL register to check the FIFO space, the read value
> must be masked. The operation is repeated explicitly in several places. This
> change refactors the read-and-mask code into a function call.
> 
> Change-Id: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef
> Signed-off-by: Dave Gordon 

Looks like an unrelated patch and probably collides with Mika's forcewake
refactoring. Please rebase on top of that series if still needed.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_uncore.c |   19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 46de8d7..4021831 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -47,6 +47,13 @@ assert_device_not_suspended(struct drm_i915_private 
> *dev_priv)
> "Device suspended\n");
>  }
>  
> +static inline u32 fifo_free_entries(struct drm_i915_private *dev_priv)
> +{
> + u32 count = __raw_i915_read32(dev_priv, GTFIFOCTL);
> +
> + return count & GT_FIFO_FREE_ENTRIES_MASK;
> +}
> +
>  static void __gen6_gt_wait_for_thread_c0(struct drm_i915_private *dev_priv)
>  {
>   /* w/a for a sporadic read returning 0 by waiting for the GT
> @@ -154,16 +161,15 @@ static int __gen6_gt_wait_for_fifo(struct 
> drm_i915_private *dev_priv)
>   /* On VLV, FIFO will be shared by both SW and HW.
>* So, we need to read the FREE_ENTRIES everytime */
>   if (IS_VALLEYVIEW(dev_priv->dev))
> - dev_priv->uncore.fifo_count =
> - __raw_i915_read32(dev_priv, GTFIFOCTL) &
> - GT_FIFO_FREE_ENTRIES_MASK;
> + dev_priv->uncore.fifo_count = fifo_free_entries(dev_priv);
>  
>   if (dev_priv->uncore.fifo_count < GT_FIFO_NUM_RESERVED_ENTRIES) {
>   int loop = 500;
> - u32 fifo = __raw_i915_read32(dev_priv, GTFIFOCTL) & 
> GT_FIFO_FREE_ENTRIES_MASK;
> + u32 fifo = fifo_free_entries(dev_priv);
> +
>   while (fifo <= GT_FIFO_NUM_RESERVED_ENTRIES && loop--) {
>   udelay(10);
> - fifo = __raw_i915_read32(dev_priv, GTFIFOCTL) & 
> GT_FIFO_FREE_ENTRIES_MASK;
> + fifo = fifo_free_entries(dev_priv);
>   }
>   if (WARN_ON(loop < 0 && fifo <= GT_FIFO_NUM_RESERVED_ENTRIES))
>   ++ret;
> @@ -505,8 +511,7 @@ void intel_uncore_forcewake_reset(struct drm_device *dev, 
> bool restore)
>  
>   if (IS_GEN6(dev) || IS_GEN7(dev))
>   dev_priv->uncore.fifo_count =
> - __raw_i915_read32(dev_priv, GTFIFOCTL) &
> - GT_FIFO_FREE_ENTRIES_MASK;
> + fifo_free_entries(dev_priv);
>   }
>  
>   spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
> -- 
> 1.7.9.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Disable 'get seqno' workaround for VLV

[Daniel Vetter]

On Tue, Dec 09, 2014 at 12:59:08PM +, john.c.harri...@intel.com wrote:
> From: Dave Gordon 
> 
> There is a workaround for a hardware bug when reading the seqno from the 
> status
> page. The bug does not exist on VLV however, the workaround was still being
> applied.

Given how much trouble the missed seqno fun cause us I'd like more
justification. What kind of (stress)-testing has been done here? And
you're sure you've never seen the little dmesg notice that the kernel
switched to polling?
-Daniel

> 
> Change-Id: Ic781fdb31e1f794ce1fa8a6d0d5ee379756c5db6
> Signed-off-by: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 3887f1a..f990ce4 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2367,7 +2367,10 @@ int intel_init_render_ring_buffer(struct drm_device 
> *dev)
>   ring->irq_get = gen6_ring_get_irq;
>   ring->irq_put = gen6_ring_put_irq;
>   ring->irq_enable_mask = GT_RENDER_USER_INTERRUPT;
> - ring->get_seqno = gen6_ring_get_seqno;
> + if (IS_VALLEYVIEW(dev))
> + ring->get_seqno = ring_get_seqno;
> + else
> + ring->get_seqno = gen6_ring_get_seqno;
>   ring->set_seqno = ring_set_seqno;
>   if (i915_semaphore_is_enabled(dev)) {
>   ring->semaphore.sync_to = gen6_ring_sync;
> -- 
> 1.7.9.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/10] drm/i915: Add extra add_request calls

[Daniel Vetter]

On Tue, Dec 09, 2014 at 12:59:09PM +, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> The scheduler needs to track batch buffers by request without extra, non-batch
> buffer work being attached to the same request. This means that anywhere which
> adds work to the ring should explicitly call i915_add_request() when it has
> finished writing to the ring.
> 
> The add_request() function does extra work, such as flushing caches, that does
> not necessarily want to be done everywhere. Instead, a new
> i915_add_request_wo_flush() function has been added which skips the cache 
> flush
> and just tidies up the request structure.
> 
> Note, much of this patch was implemented by Naresh Kumar Kachhi for pending
> power management improvements. However, it is also directly applicable to the
> scheduler work as noted above.
> 
> Change-Id: I66a6861118ee8e7ad7ca6c80c71a3b256db92e18
> For: VIZ-1587
> Signed-off-by: John Harrison 

For easier review I think it'd be better to split this into the prep patch
to rework add_request and then patches to roll it out. Some of the places
you're adding an add_requst too look questionable to me. More comments
below.

After reading through the patch (see below for comments) I think there's
only two places where we need to add requests:
- at the end of pageflips, unconditionally (to catch any semaphores
  already emitted if something fails)
- after ring init in init_hw (but perhaps with some of the restructuring
  in-flight applied to make it less messy).

Then a WARN_ON in gpu_idle to make sure no request ever escaped. Should
all be separate patches I think (so that we have a nice empty space in the
commit message for explanation why this works).

This patch here just sprinkles lots of add_requests all over which ime
tends to blow up sooner or later since it's much harder to understand and
leaves no room for selfchecks in the code to catch bugs.

Cheers, Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |9 --
>  drivers/gpu/drm/i915/i915_gem.c  |   45 
> --
>  drivers/gpu/drm/i915/i915_gem_context.c  |9 ++
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c   |4 +--
>  drivers/gpu/drm/i915/i915_gem_gtt.c  |9 ++
>  drivers/gpu/drm/i915/i915_gem_render_state.c |2 +-
>  drivers/gpu/drm/i915/intel_display.c |   23 +
>  drivers/gpu/drm/i915/intel_lrc.c |4 +--
>  8 files changed, 73 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 11e85cb..0e280c4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2553,7 +2553,7 @@ static inline void i915_gem_object_unpin_pages(struct 
> drm_i915_gem_object *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);
> +  struct intel_engine_cs *to, bool add_request);
>  void i915_vma_move_to_active(struct i915_vma *vma,
>struct intel_engine_cs *ring);
>  int i915_gem_dumb_create(struct drm_file *file_priv,
> @@ -2641,9 +2641,12 @@ int __must_check i915_gpu_idle(struct drm_device *dev);
>  int __must_check i915_gem_suspend(struct drm_device *dev);
>  int __i915_add_request(struct intel_engine_cs *ring,
>  struct drm_file *file,
> -struct drm_i915_gem_object *batch_obj);
> +struct drm_i915_gem_object *batch_obj,
> +bool flush_caches);
>  #define i915_add_request(ring) \
> - __i915_add_request(ring, NULL, NULL)
> + __i915_add_request(ring, NULL, NULL, true)
> +#define i915_add_request_no_flush(ring) \
> + __i915_add_request(ring, NULL, NULL, false)
>  int __i915_wait_request(struct drm_i915_gem_request *req,
>   unsigned reset_counter,
>   bool interruptible,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index de241eb..b022a2d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2419,7 +2419,8 @@ i915_gem_get_seqno(struct drm_device *dev, u32 *seqno)
>  
>  int __i915_add_request(struct intel_engine_cs *ring,
>  struct drm_file *file,
> -struct drm_i915_gem_object *obj)
> +struct drm_i915_gem_object *obj,
> +bool flush_caches)
>  {
>   struct drm_i915_private *dev_priv = ring->dev->dev_private;
>   struct drm_i915_gem_request *request;
> @@ -2445,12 +2446,11 @@ int __i915_add_request(struct intel_engine_cs *ring,
>* is that the flush _must_ happen before the next request, no matter
>* what.
>*/
> - if (i915.enable_execlists) {
> - ret = logical_ring_flush_all_caches(ringbuf);
> - if

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two

[Daniel Vetter]

On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> The scheduler decouples the submission of batch buffers to the driver with 
> their
> submission to the hardware. This basically means splitting the execbuffer()
> function in half. This change rearranges some code ready for the split to 
> occur.

Now there's the curios question: Where will the split in top/bottom halves
be? Without that I have no idea whether it makes sense and so can't review
this patch. At least if the goal is to really prep for the scheduler and
not just move a few lines around ;-)
-Daniel

> 
> Change-Id: Icc9c8afaac18821f3eb8a151a49f918f90c068a3
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   47 
> +---
>  drivers/gpu/drm/i915/intel_lrc.c   |   17 +++---
>  2 files changed, 40 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index f09501c..a339556 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -848,10 +848,7 @@ i915_gem_execbuffer_move_to_gpu(struct intel_engine_cs 
> *ring,
>   if (flush_domains & I915_GEM_DOMAIN_GTT)
>   wmb();
>  
> - /* Unconditionally invalidate gpu caches and ensure that we do flush
> -  * any residual writes from the previous batch.
> -  */
> - return intel_ring_invalidate_all_caches(ring);
> + return 0;
>  }
>  
>  static bool
> @@ -1123,14 +1120,6 @@ i915_gem_ringbuffer_submission(struct drm_device *dev, 
> struct drm_file *file,
>   }
>   }
>  
> - ret = i915_gem_execbuffer_move_to_gpu(ring, vmas);
> - if (ret)
> - goto error;
> -
> - ret = i915_switch_context(ring, ctx);
> - if (ret)
> - goto error;
> -
>   instp_mode = args->flags & I915_EXEC_CONSTANTS_MASK;
>   instp_mask = I915_EXEC_CONSTANTS_MASK;
>   switch (instp_mode) {
> @@ -1168,6 +1157,28 @@ i915_gem_ringbuffer_submission(struct drm_device *dev, 
> struct drm_file *file,
>   goto error;
>   }
>  
> + ret = i915_gem_execbuffer_move_to_gpu(ring, vmas);
> + if (ret)
> + goto error;
> +
> + i915_gem_execbuffer_move_to_active(vmas, ring);
> +
> + /* To be split into two functions here... */
> +
> + intel_runtime_pm_get(dev_priv);
> +
> + /* Unconditionally invalidate gpu caches and ensure that we do flush
> +  * any residual writes from the previous batch.
> +  */
> + ret = intel_ring_invalidate_all_caches(ring);
> + if (ret)
> + goto error;
> +
> + /* Switch to the correct context for the batch */
> + ret = i915_switch_context(ring, ctx);
> + if (ret)
> + goto error;
> +
>   if (ring == &dev_priv->ring[RCS] &&
>   instp_mode != dev_priv->relative_constants_mode) {
>   ret = intel_ring_begin(ring, 4);
> @@ -1208,15 +1219,18 @@ i915_gem_ringbuffer_submission(struct drm_device 
> *dev, struct drm_file *file,
>   exec_start, exec_len,
>   dispatch_flags);
>   if (ret)
> - return ret;
> + goto error;
>   }
>  
>   trace_i915_gem_ring_dispatch(intel_ring_get_request(ring), 
> dispatch_flags);
>  
> - i915_gem_execbuffer_move_to_active(vmas, ring);
>   i915_gem_execbuffer_retire_commands(dev, file, ring, batch_obj);
>  
>  error:
> + /* intel_gpu_busy should also get a ref, so it will free when the device
> +  * is really idle. */
> + intel_runtime_pm_put(dev_priv);
> +
>   kfree(cliprects);
>   return ret;
>  }
> @@ -1335,8 +1349,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
> *data,
>   return -EINVAL;
>   }
>  
> - intel_runtime_pm_get(dev_priv);
> -
>   ret = i915_mutex_lock_interruptible(dev);
>   if (ret)
>   goto pre_mutex_err;
> @@ -1467,9 +1479,6 @@ err:
>   mutex_unlock(&dev->struct_mutex);
>  
>  pre_mutex_err:
> - /* intel_gpu_busy should also get a ref, so it will free when the device
> -  * is really idle. */
> - intel_runtime_pm_put(dev_priv);
>   return ret;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 037cbd5..f16b15d 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -630,10 +630,7 @@ static int execlists_move_to_gpu(struct intel_ringbuffer 
> *ringbuf,
>   if (flush_domains & I915_GEM_DOMAIN_GTT)
>   wmb();
>  
> - /* Unconditionally invalidate gpu caches and ensure that we do flush
> -  * any residual writes from the previous batch.
> -  */
> - return logical_ring_invalidate_all_caches(ringbuf);
> + return 0;
>  }
>  
>  

Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for batch buffer pools

[Bloomfield, Jon]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Daniel Vetter
> Sent: Tuesday, December 09, 2014 1:18 PM
> To: Nguyen, Michael H
> Cc: Brad Volkin; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for
> batch buffer pools
> 
> On Mon, Dec 08, 2014 at 02:33:46PM -0800, michael.h.ngu...@intel.com
> wrote:
> > From: Brad Volkin 
> >
> > This adds a small module for managing a pool of batch buffers.
> > The only current use case is for the command parser, as described in
> > the kerneldoc in the patch. The code is simple, but separating it out
> > makes it easier to change the underlying algorithms and to extend to
> > future use cases should they arise.
> >
> > The interface is simple: init to create an empty pool, fini to clean
> > it up, get to obtain a new buffer. Note that all buffers are expected
> > to be inactive before cleaning up the pool.
> >
> > Locking is currently based on the caller holding the struct_mutex.
> > We already do that in the places where we will use the batch pool for
> > the command parser.
> >
> > v2:
> > - s/BUG_ON/WARN_ON/ for locking assertions
> > - Remove the cap on pool size
> > - Switch from alloc/free to init/fini
> >
> > v3:
> > - Idiomatic looping structure in _fini
> > - Correct handling of purged objects
> > - Don't return a buffer that's too much larger than needed
> >
> > v4:
> > - Rebased to latest -nightly
> >
> > v5:
> > - Remove _put() function and clean up comments to match
> >
> > v6:
> > - Move purged check inside the loop (danvet, from v4 1/7 feedback)
> >
> > v7:
> > - Use single list instead of two. (Chris W)
> > - s/active_list/cache_list
> > - Squashed in debug patches (Chris W)
> >   drm/i915: Add a batch pool debugfs file
> >
> >   It provides some useful information about the buffers in
> >   the global command parser batch pool.
> >
> >   v2: rebase on global pool instead of per-ring pools
> >   v3: rebase
> >
> >   drm/i915: Add batch pool details to i915_gem_objects debugfs
> >
> >   To better account for the potentially large memory consumption
> >   of the batch pool.
> >
> > Issue: VIZ-4719
> > Signed-off-by: Brad Volkin 
> > ---
> >  Documentation/DocBook/drm.tmpl |   5 ++
> >  drivers/gpu/drm/i915/Makefile  |   1 +
> >  drivers/gpu/drm/i915/i915_debugfs.c|  71 ++--
> >  drivers/gpu/drm/i915/i915_drv.h|  21 +
> >  drivers/gpu/drm/i915/i915_gem.c|   1 +
> >  drivers/gpu/drm/i915/i915_gem_batch_pool.c | 132
> > +
> >  6 files changed, 222 insertions(+), 9 deletions(-)  create mode
> > 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.c
> >
> > diff --git a/Documentation/DocBook/drm.tmpl
> > b/Documentation/DocBook/drm.tmpl index 85287cb..022923a 100644
> > --- a/Documentation/DocBook/drm.tmpl
> > +++ b/Documentation/DocBook/drm.tmpl
> > @@ -4029,6 +4029,11 @@ int num_ioctls;
> > !Idrivers/gpu/drm/i915/i915_cmd_parser.c
> >
> >
> > +Batchbuffer Pools
> > +!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool
> > +!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c
> > +  
> > +  
> >  Logical Rings, Logical Ring Contexts and
> > Execlists  !Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings,
> > Logical Ring Contexts and Execlists
> > !Idrivers/gpu/drm/i915/intel_lrc.c
> > diff --git a/drivers/gpu/drm/i915/Makefile
> > b/drivers/gpu/drm/i915/Makefile index e4083e4..c8dbb37d 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -19,6 +19,7 @@ i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
> >
> >  # GEM code
> >  i915-y += i915_cmd_parser.o \
> > + i915_gem_batch_pool.o \
> >   i915_gem_context.o \
> >   i915_gem_render_state.o \
> >   i915_gem_debug.o \
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index d0e445e..3c3bf98 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -359,6 +359,33 @@ static int per_file_stats(int id, void *ptr, void
> *data)
> > return 0;
> >  }
> >
> > +#define print_file_stats(m, name, stats) \
> > +   seq_printf(m, "%s: %u objects, %zu bytes (%zu active, %zu inactive,
> %zu global, %zu shared, %zu unbound)\n", \
> > +  name, \
> > +  stats.count, \
> > +  stats.total, \
> > +  stats.active, \
> > +  stats.inactive, \
> > +  stats.global, \
> > +  stats.shared, \
> > +  stats.unbound)

"print_file_stats" might be better named "print_obj_stats" or similar. As it 
stands
there is nothing in its name to suggest its purpose is to describe an object.


> > +
> > +static void print_batch_pool_stats(struct seq_file *m,
> > +  struct drm_i915_private *dev_priv) {
> > +   struct drm_i915_gem_object *obj;
> 

Re: [Intel-gfx] [PATCH] drm/i915: Quietly reject attempts to create non-pagealigned stolen objects

[Chris Wilson]

On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > This added as a BUG_ON as it considered that no one would ever request
> > an unaligned object. However, it turns out that some BIOSes will
> > allocate a scanout that is offset from 0 and not aligned to a page
> > boundary, and we were passing this through and hitting the BUG_ON during
> > boot.
> > 
> > Quietly reject such a request to reserve the unaligned stolen object and
> > let the boot continue, restoring previous behaviour (i.e. no BIOS
> > framebuffer preservation).
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883
> > Signed-off-by: Chris Wilson 
> > Cc: sta...@vger.kernel.org
> > ---
> >  drivers/gpu/drm/i915/i915_gem_stolen.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > index 5c616ec2c5c8..a3bc0fa07c6c 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > @@ -646,13 +646,15 @@ i915_gem_object_create_stolen_for_preallocated(struct 
> > drm_device *dev,
> > DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, 
> > gtt_offset=%x, size=%x\n",
> > stolen_offset, gtt_offset, size);
> >  
> > -   /* KISS and expect everything to be page-aligned */
> > -   BUG_ON(stolen_offset & 4095);
> > -   BUG_ON(size & 4095);
> > -
> > if (WARN_ON(size == 0))
> > return NULL;
> >  
> > +   /* KISS and expect everything to be GTT page-aligned */
> > +   if ((stolen_offset | size) & 4095) {
> 
> Imo we should stil WARN_ON and fixup up the takeover code to align things
> properly ...

You shot down my idea for storing deltas into objects in the past...

The BIOS scanout is properly aligned to the rules of the display engine,
just not according to our mm restrictions. The bigger question is
whether our 1:1 offset-to-stolen mapping is correct. It could well be
that that the framebuffer is at stolen address 0, but just has a GTT
offset.

So the only question is whether we reject the object reservation at the
stolen layer or at the plane config layer. I decided that stolen was
better, because it is failing to meet our mm restrictions not
hardware restrictions.
-Chris

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

Re: [Intel-gfx] [PATCH v3] drm/i915/bdw: Fix the write setting up the WIZ hashing mode

[Damien Lespiau]

On Wed, Dec 10, 2014 at 11:42:13AM +0200, Jani Nikula wrote:
> Pushed to drm-intel-next-fixes, replacing the old version. Thanks for
> the patch.
> 
> Now the question is, do we want [1] for 3.19 or 3.20?
> 
> [1] 
> http://mid.gmane.org/1418060138-5004-1-git-send-email-damien.lesp...@intel.com

I think that one is for 3.20, not really fixing a bug.

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

[Intel-gfx] [PULL] topic/core-stuff

[Daniel Vetter]

Hi Dave,

Decided to send a pull request for my misc drm branch because of teh
memset patch from Thierry for drm_*_cleanup functions (fixes drivers using
deferred probe) and the patch from Takashi. Everything else fairly
trivial.

Cheers, Daniel


The following changes since commit e5b5341c28c66a122982d3d8822a4f9a0938f923:

  drm/atomic: clear plane's CRTC and FB when shutting down (2014-11-27 15:39:11 
+0100)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-12-10

for you to fetch changes up to a18c0af171bfb875012da26f23df051004726973:

  drm: Zero out DRM object memory upon cleanup (2014-12-10 12:05:56 +0100)


Martin Peres (2):
  drm: fix a word repetition in a comment
  drm: fix a typo in a comment

Sean Paul (1):
  drm/Documentation: Fix rowspan value in drm-kms-properties

Stefan Brüns (3):
  drm/edid: move drm_edid_is_zero to top, make edid argument const
  drm/edid: shorten log output in case of all zeroes edid block
  drm/edid: new drm_edid_block_checksum helper function V3

Takashi Iwai (1):
  drm: Fix memory leak at error path of drm_read()

Thierry Reding (2):
  drm/edid: Restore kerneldoc consistency
  drm: Zero out DRM object memory upon cleanup

 Documentation/DocBook/drm.tmpl |  2 +-
 drivers/gpu/drm/drm_crtc.c | 13 +++--
 drivers/gpu/drm/drm_edid.c | 42 +++---
 drivers/gpu/drm/drm_fops.c |  1 +
 drivers/gpu/drm/drm_irq.c  |  2 +-
 5 files changed, 41 insertions(+), 19 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PRTS] Kernel Patch testing [PATCH 10/10] drm/i915: Cache ringbuf pointer in

[John Harrison]

Is anyone else having problems reading the PRTS logs?

It looks like I got a merge failure complaint, presumably because I need 
to rebase to a newer nightly tree. However, the log file itself does not 
say anything useful. There is a bit of pre-amble which finishes by 
saying 'This file include 3 part: output, error and dmesg. The file 
opening is: 4260699.out' and then I get 13MB of repeated '' tags and 
that's it. Not a particularly useful log!


Also, why are the emails copied to 'quarkon...@wo.com.cn'?


On 09/12/2014 14:07, shuang...@intel.com wrote:
Re:[PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in
Received the [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] 
drm/i915: Cache ringbuf pointer in mail(2014-12-09-22:10:10)

task_id(2014-12-09-22:10:10)4212
user_id(2014-12-09-22:10:10)53
user_name(2014-12-09-22:10:10)  Harrison
user_email(2014-12-09-22:10:10) john.c.harri...@intel.com
task_result link(2014-12-09-22:10:10) 
http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=4212




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

Re: [Intel-gfx] [PRTS] Kernel Patch testing [PATCH 10/10] drm/i915: Cache ringbuf pointer in

[He, Shuang]

From: Harrison, John C
Sent: Wednesday, December 10, 2014 9:06 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Cc: He, Shuang
Subject: Re: [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in

Is anyone else having problems reading the PRTS logs?
[He, Shuang] Hello, thanks for reporting back this issue


It looks like I got a merge failure complaint, presumably because I need to 
rebase to a newer nightly tree. However, the log file itself does not say 
anything useful. There is a bit of pre-amble which finishes by saying 'This 
file include 3 part: output, error and dmesg. The file opening is: 4260699.out' 
and then I get 13MB of repeated '' tags and that's it. Not a particularly 
useful log!
[He, Shuang] I can reproduce this issue, we'll fix the log, actually we haven't 
upload any log to the server for building kernel, so I think this is a bug for 
web UI for PRTS, we'll figure it out. And also we're figuring out better way to 
make it work for you. For example, the main issue here is that even we give you 
the failure and the baseline commit, you may not be able to find it in anywhere 
due to rebase of drm-intel-nightly tree, it will be still a pain for you to 
figure out what have happened. So the easiest way to have your patch finally 
applied to the baseline tree would be, we provide the exactly baseline commit 
and the link that you can pull in that commit, so you can simply rebase your 
patch to that specific commit, hence reduce the effort on both sides. And we're 
working to set up a place outside intel to hold those baseline commit.
Thanks
--Shuang

Also, why are the emails copied to 
'quarkon...@wo.com.cn'?

On 09/12/2014 14:07, shuang...@intel.com wrote:
Re:[PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: Cache 
ringbuf pointer in

Received the [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in mail(2014-12-09-22:10:10)

task_id(2014-12-09-22:10:10)

4212

user_id(2014-12-09-22:10:10)

53

user_name(2014-12-09-22:10:10)

Harrison

user_email(2014-12-09-22:10:10)

john.c.harri...@intel.com

task_result link(2014-12-09-22:10:10)

http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=4212


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

Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: add component support

[Imre Deak]

On Wed, 2014-12-10 at 10:22 +0200, Jani Nikula wrote:
> On Tue, 09 Dec 2014, Imre Deak  wrote:
> > Register a component to be used to interface with the snd_hda_intel
> > driver. This is meant to replace the same interface that is currently
> > based on module symbol lookup.
> >
> > v2:
> > - change roles between the hda and i915 components (Daniel)
> > - add the implementation to a new file (Jani)
> > - use better namespacing (Jani)
> > v3:
> > - move the implementation to intel_audio.c (Daniel)
> > - rename display_component to audio_component (Daniel)
> > - add kerneldoc (Daniel)
> >
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_component.c |  27 +
> 
> Ooops?

Yep, missed git rm:/

> 
> J.
> 
> >  drivers/gpu/drm/i915/i915_dma.c   |   4 ++
> >  drivers/gpu/drm/i915/i915_drv.h   |   3 +
> >  drivers/gpu/drm/i915/intel_audio.c| 110 
> > ++
> >  drivers/gpu/drm/i915/intel_drv.h  |   2 +
> >  include/drm/i915_component.h  |  38 
> >  6 files changed, 184 insertions(+)
> >  create mode 100644 drivers/gpu/drm/i915/i915_component.c
> >  create mode 100644 include/drm/i915_component.h
> >
> > diff --git a/drivers/gpu/drm/i915/i915_component.c 
> > b/drivers/gpu/drm/i915/i915_component.c
> > new file mode 100644
> > index 000..95dd087
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/i915_component.c
> > @@ -0,0 +1,27 @@
> > +/*
> > + * Copyright © 2014 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software"),
> > + * to deal in the Software without restriction, including without 
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including the 
> > next
> > + * paragraph) shall be included in all copies or substantial portions of 
> > the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> > OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > DEALINGS
> > + * IN THE SOFTWARE.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include "intel_drv.h"
> > +
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 887d88f..f6334d0 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -830,6 +830,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
> > long flags)
> >  
> > intel_runtime_pm_enable(dev_priv);
> >  
> > +   i915_audio_component_init(dev_priv);
> > +
> > return 0;
> >  
> >  out_power_well:
> > @@ -870,6 +872,8 @@ int i915_driver_unload(struct drm_device *dev)
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > int ret;
> >  
> > +   i915_audio_component_cleanup(dev_priv);
> > +
> > ret = i915_gem_suspend(dev);
> > if (ret) {
> > DRM_ERROR("failed to idle hardware: %d\n", ret);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 0961d7f..3c2d9c7 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1713,6 +1713,9 @@ struct drm_i915_private {
> > struct drm_property *broadcast_rgb_property;
> > struct drm_property *force_audio_property;
> >  
> > +   /* hda/i915 audio component */
> > +   bool audio_component_registered;
> > +
> > uint32_t hw_context_size;
> > struct list_head context_list;
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 2c7ed5c..ee41b88 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -22,6 +22,9 @@
> >   */
> >  
> >  #include 
> > +#include 
> > +#include 
> > +#include "intel_drv.h"
> >  
> >  #include 
> >  #include 
> > @@ -461,3 +464,110 @@ void intel_init_audio(struct drm_device *dev)
> > dev_priv->display.audio_codec_disable = ilk_audio_codec_disable;
> > }
> >  }
> > +
> > +static void i915_audio_component_get_power(struct device *dev)
> > +{
> > +   intel_display_power_get(dev_to_i915(dev), POWER_DOMAIN_AUDIO);
> > +}
> > +
> > +static void i915_audio_component_put_power(struct device *dev)
> > +{
> > +   intel_display_power_put(dev_to_i915(dev), POWER_DOMAIN_AUDIO);
> > +}
> > +
> > +/* Get CDC

Re: [Intel-gfx] [PRTS] Kernel Patch testing [PATCH 10/10] drm/i915: Cache ringbuf pointer in

[He, Shuang]

From: Harrison, John C
Sent: Wednesday, December 10, 2014 9:06 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Cc: He, Shuang
Subject: Re: [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in

Is anyone else having problems reading the PRTS logs?

It looks like I got a merge failure complaint, presumably because I need to 
rebase to a newer nightly tree. However, the log file itself does not say 
anything useful. There is a bit of pre-amble which finishes by saying 'This 
file include 3 part: output, error and dmesg. The file opening is: 4260699.out' 
and then I get 13MB of repeated '' tags and that's it. Not a particularly 
useful log!

Also, why are the emails copied to 
'quarkon...@wo.com.cn'?
[He, Shuang] It's my personal push mail, I'll get short message on my mobile 
phone, when you send to that email. So basically I can check what's going on 
with my mobile phone. And take action accordingly, like this email did.

Thanks
   --Shuang


On 09/12/2014 14:07, shuang...@intel.com wrote:
Re:[PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: Cache 
ringbuf pointer in

Received the [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in mail(2014-12-09-22:10:10)

task_id(2014-12-09-22:10:10)

4212

user_id(2014-12-09-22:10:10)

53

user_name(2014-12-09-22:10:10)

Harrison

user_email(2014-12-09-22:10:10)

john.c.harri...@intel.com

task_result link(2014-12-09-22:10:10)

http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=4212


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

[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[Daniel Vetter]

Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.

We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.

The idea to use __builtin_constant_p is from Chris Wilson.

v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.

Also use a temporary variable to only evaluate the condition once,
suggested by Damien.

v3: It's crazy but apparently 32bit gcc can't compile out the
BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
why, but until clue grows just disable this nifty idea on 32bit
builds. Reported by 0-day builder.

Cc: Damien Lespiau 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Dave Gordon 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 13 -
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  6 +++---
 drivers/gpu/drm/i915/intel_display.c |  4 ++--
 drivers/gpu/drm/i915/intel_uncore.c  |  4 ++--
 5 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445eca9ce..f44a844a48db 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum 
intel_display_power_domain domain)
case POWER_DOMAIN_INIT:
return "INIT";
default:
-   WARN_ON(1);
+   MISSING_CASE();
return "?";
}
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95dfa2dd35b9..51d7948a7e88 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -58,7 +58,18 @@
 #define DRIVER_DATE"20141205"
 
 #undef WARN_ON
-#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
+#if BITS_PER_LONG == 64
+#define WARN_ON(x) ({ \
+   bool __i915_warn_cond = (x); \
+   if (__builtin_constant_p(__i915_warn_cond)) \
+   BUILD_BUG_ON(__i915_warn_cond); \
+   WARN(__i915_warn_cond, "WARN_ON(" #x ")"); })
+#else
+/* Somehow 32bit gcc can't compile out the BUILD_BUG_ON. */
+#define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")
+#endif
+
+#define MISSING_CASE() WARN(1, "Missing switch case in %s\n", __func__);
 
 enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ac03a382000b..3b5807c11427 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
}
 
return pte;
@@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
}
 
return pte;
@@ -1146,7 +1146,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 8)
gen8_ppgtt_enable(dev);
else
-   WARN_ON(1);
+   MISSING_CASE();
 
if (ppgtt) {
for_each_ring(ring, dev_priv, i) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d5153a4f90fe..b7155d5efc10 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4847,7 +4847,7 @@ static void cherryview_set_cdclk(struct drm_device *dev, 
int cdclk)
cmd = 0;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
return;
}
 
@@ -8224,7 +8224,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d75b4bf..83ab530fee06 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1202,7 +1202,7 @@ void intel_uncore_init(struct drm_device *dev)
 
switch (INTEL_INFO(dev)->gen) {
default:
-   WARN_ON(1);
+ 

Re: [Intel-gfx] [RFC][PATCH 6/8] drm/i915: Remove intel_crtc->new_config pointer

[Ander Conselvan de Oliveira]

On 12/08/2014 06:36 PM, Daniel Vetter wrote:

On Mon, Dec 08, 2014 at 05:21:07PM +0200, Ander Conselvan de Oliveira wrote:

There are no more users of that pointer since the new config is now
passed down the call chain during mode set. Also, when the switch to
atomic happens, the right config (state) should be derived from an
atomic state structure.


Ah, doesn't seem much work actually to remove our usage of ->new_config.
Which is nice since it'll align us more with how the helpers work.


Except for the ugliness in patch 5, it was pretty straight forward. But 
that can be fixed once we have a global state object.



So overall I think this patch series is good to go (but I've done only a
rather cursory high-level reading).


For some reason PRTS ignored this one (maybe because it is an RFC?), so 
I submitted a task manually. If that succeeds, I'll resend without the 
RFC status.


Cheers,
Ander



Thanks, Daniel


---
  drivers/gpu/drm/i915/intel_display.c | 46 
  drivers/gpu/drm/i915/intel_drv.h |  1 -
  2 files changed, 10 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a9f3034..a032a1d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8583,7 +8583,6 @@ retry:

intel_crtc = to_intel_crtc(crtc);
intel_crtc->new_enabled = true;
-   intel_crtc->new_config = &intel_crtc->config;
old->dpms_mode = connector->dpms;
old->load_detect_temp = true;
old->release_fb = NULL;
@@ -8623,10 +8622,6 @@ retry:

   fail:
intel_crtc->new_enabled = crtc->enabled;
-   if (intel_crtc->new_enabled)
-   intel_crtc->new_config = &intel_crtc->config;
-   else
-   intel_crtc->new_config = NULL;
  fail_unlock:
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
@@ -8653,7 +8648,6 @@ void intel_release_load_detect_pipe(struct drm_connector 
*connector,
to_intel_connector(connector)->new_encoder = NULL;
intel_encoder->new_crtc = NULL;
intel_crtc->new_enabled = false;
-   intel_crtc->new_config = NULL;
intel_set_mode(crtc, NULL, 0, 0, NULL);

if (old->release_fb) {
@@ -9839,14 +9833,8 @@ static void 
intel_modeset_update_staged_output_state(struct drm_device *dev)
to_intel_crtc(encoder->base.crtc);
}

-   for_each_intel_crtc(dev, crtc) {
+   for_each_intel_crtc(dev, crtc)
crtc->new_enabled = crtc->base.enabled;
-
-   if (crtc->new_enabled)
-   crtc->new_config = &crtc->config;
-   else
-   crtc->new_config = NULL;
-   }
  }

  /**
@@ -10355,12 +10343,8 @@ intel_modeset_update_state(struct drm_device *dev, 
unsigned prepare_pipes)
intel_modeset_commit_output_state(dev);

/* Double check state. */
-   for_each_intel_crtc(dev, intel_crtc) {
+   for_each_intel_crtc(dev, intel_crtc)
WARN_ON(intel_crtc->base.enabled != 
intel_crtc_in_use(&intel_crtc->base));
-   WARN_ON(intel_crtc->new_config &&
-   intel_crtc->new_config != &intel_crtc->config);
-   WARN_ON(intel_crtc->base.enabled != !!intel_crtc->new_config);
-   }

list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (!connector->encoder || !connector->encoder->crtc)
@@ -10957,9 +10941,6 @@ static int __intel_set_mode(struct drm_crtc *crtc,

*saved_mode = crtc->mode;

-   if (modeset_pipes)
-   to_intel_crtc(crtc)->new_config = pipe_config;
-
/*
 * See if the config requires any additional preparation, e.g.
 * to adjust global state with pipes off.  We need to do this
@@ -10984,7 +10965,13 @@ static int __intel_set_mode(struct drm_crtc *crtc,
goto done;

for_each_intel_crtc_masked(dev, modeset_pipes, intel_crtc) {
-   struct intel_crtc_state *state = intel_crtc->new_config;
+   struct intel_crtc_state *state;
+
+   if (&intel_crtc->base == crtc)
+   state = pipe_config;
+   else
+   state = intel_crtc->config;
+
ret = dev_priv->display.crtc_compute_clock(intel_crtc,
   state);
if (ret) {
@@ -11014,7 +11001,6 @@ static int __intel_set_mode(struct drm_crtc *crtc,
/* mode_set/enable/disable functions rely on a correct pipe
 * config. */
to_intel_crtc(crtc)->config = *pipe_config;
-   to_intel_crtc(crtc)->new_config = &to_intel_crtc(crtc)->config;

/*
 * Calcu

Re: [Intel-gfx] [PATCH] drm/i915: Quietly reject attempts to create non-pagealigned stolen objects

[Daniel Vetter]

On Wed, Dec 10, 2014 at 11:13:28AM +, Chris Wilson wrote:
> On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > > This added as a BUG_ON as it considered that no one would ever request
> > > an unaligned object. However, it turns out that some BIOSes will
> > > allocate a scanout that is offset from 0 and not aligned to a page
> > > boundary, and we were passing this through and hitting the BUG_ON during
> > > boot.
> > > 
> > > Quietly reject such a request to reserve the unaligned stolen object and
> > > let the boot continue, restoring previous behaviour (i.e. no BIOS
> > > framebuffer preservation).
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883
> > > Signed-off-by: Chris Wilson 
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem_stolen.c | 10 ++
> > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> > > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > index 5c616ec2c5c8..a3bc0fa07c6c 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > @@ -646,13 +646,15 @@ 
> > > i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
> > >   DRM_DEBUG_KMS("creating preallocated stolen object: stolen_offset=%x, 
> > > gtt_offset=%x, size=%x\n",
> > >   stolen_offset, gtt_offset, size);
> > >  
> > > - /* KISS and expect everything to be page-aligned */
> > > - BUG_ON(stolen_offset & 4095);
> > > - BUG_ON(size & 4095);
> > > -
> > >   if (WARN_ON(size == 0))
> > >   return NULL;
> > >  
> > > + /* KISS and expect everything to be GTT page-aligned */
> > > + if ((stolen_offset | size) & 4095) {
> > 
> > Imo we should stil WARN_ON and fixup up the takeover code to align things
> > properly ...
> 
> You shot down my idea for storing deltas into objects in the past...
> 
> The BIOS scanout is properly aligned to the rules of the display engine,
> just not according to our mm restrictions. The bigger question is
> whether our 1:1 offset-to-stolen mapping is correct. It could well be
> that that the framebuffer is at stolen address 0, but just has a GTT
> offset.
> 
> So the only question is whether we reject the object reservation at the
> stolen layer or at the plane config layer. I decided that stolen was
> better, because it is failing to meet our mm restrictions not
> hardware restrictions.

The framebuffer layer can very much cope with offsets, so no need to
reject it. We just need to patch up the framebuffer we create a bit.
Offsets are in pixels but that should align well.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[Chris Wilson]

On Wed, Dec 10, 2014 at 02:49:05PM +0100, Daniel Vetter wrote:
> Faster feedback to errors is always better. This is inspired by the
> addition to WARN_ONs to mask/enable helpers for registers to make sure
> callers have the arguments ordered correctly: Pretty much always the
> arguments are static.
> 
> We use WARN_ON(1) a lot in default switch statements though where we
> should always handle all cases. So add a new macro specifically for
> that.
> 
> The idea to use __builtin_constant_p is from Chris Wilson.
> 
> v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
> Dave. My first attempt used __cond as the temp var, which is the same
> used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
> sprinkle i915 into the name.
> 
> Also use a temporary variable to only evaluate the condition once,
> suggested by Damien.
> 
> v3: It's crazy but apparently 32bit gcc can't compile out the
> BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
> why, but until clue grows just disable this nifty idea on 32bit
> builds. Reported by 0-day builder.
> 
> Cc: Damien Lespiau 
> Cc: Chris Wilson 
> Cc: Jani Nikula 
> Cc: Dave Gordon 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
>  drivers/gpu/drm/i915/i915_drv.h  | 13 -
>  drivers/gpu/drm/i915/i915_gem_gtt.c  |  6 +++---
>  drivers/gpu/drm/i915/intel_display.c |  4 ++--
>  drivers/gpu/drm/i915/intel_uncore.c  |  4 ++--
>  5 files changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index d0e445eca9ce..f44a844a48db 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum 
> intel_display_power_domain domain)
>   case POWER_DOMAIN_INIT:
>   return "INIT";
>   default:
> - WARN_ON(1);
> + MISSING_CASE();

Whilst you are doing this janitorial task, if we add the case value to
the macro, that may speed up debugging when they are hit.
-Chris

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

Re: [Intel-gfx] [PATCH v3] drm/i915/bdw: Fix the write setting up the WIZ hashing mode

[Daniel Vetter]

On Wed, Dec 10, 2014 at 12:03:20PM +, Damien Lespiau wrote:
> On Wed, Dec 10, 2014 at 11:42:13AM +0200, Jani Nikula wrote:
> > Pushed to drm-intel-next-fixes, replacing the old version. Thanks for
> > the patch.
> > 
> > Now the question is, do we want [1] for 3.19 or 3.20?
> > 
> > [1] 
> > http://mid.gmane.org/1418060138-5004-1-git-send-email-damien.lesp...@intel.com
> 
> I think that one is for 3.20, not really fixing a bug.

I suggested 3.19/dinf because it'll make merging easier. And it's
expressingly ok for Linus to merge cleanup stuff even in the merge
window/-rc1 if it makes things easier (as long as it's just obvious
refactoring without any functional change).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Changes required to enable DSI Video Mode on CHT

[Gaurav K Singh]

For CHT changes are required for calculating the correct m,n & p with
minimal error +/- for the required DSI clock, so that the correct dividor
& ctrl values are written in cck regs for DSI. This patch has been tested
on CHT RVP with 1200 x 1920 panel.

Signed-off-by: Gaurav K Singh 
---
 drivers/gpu/drm/i915/intel_dsi_pll.c |   43 ++
 1 file changed, 33 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 8957f10..9236b66 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -162,7 +162,8 @@ static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format, 
int lane_count)
 
 #endif
 
-static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp *dsi_mnp)
+static int dsi_calc_mnp(struct drm_i915_private *dev_priv,
+   u32 dsi_clk, struct dsi_mnp *dsi_mnp)
 {
u32 m, n, p;
u32 ref_clk;
@@ -173,6 +174,10 @@ static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp 
*dsi_mnp)
u32 calc_m;
u32 calc_p;
u32 m_seed;
+   u32 m_start;
+   u32 m_limit;
+   u32 n_limit;
+   u32 p_limit;
 
/* dsi_clk is expected in KHZ */
if (dsi_clk < 30 || dsi_clk > 115) {
@@ -180,18 +185,33 @@ static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp 
*dsi_mnp)
return -ECHRNG;
}
 
-   ref_clk = 25000;
+   if (IS_CHERRYVIEW(dev_priv->dev)) {
+   ref_clk = 10;
+   m_start = 70;
+   m_limit = 96;
+   n_limit = 4;
+   p_limit = 6;
+   } else if (IS_VALLEYVIEW(dev_priv->dev)) {
+   ref_clk = 25000;
+   m_start = 62;
+   m_limit = 92;
+   n_limit = 1;
+   p_limit = 6;
+   } else {
+   DRM_ERROR("Unsupported device\n");
+   return -ENODEV;
+   }
target_dsi_clk = dsi_clk;
error = 0x;
tmp_error = 0x;
calc_m = 0;
calc_p = 0;
 
-   for (m = 62; m <= 92; m++) {
-   for (p = 2; p <= 6; p++) {
+   for (m = m_start; m <= m_limit; m++) {
+   for (p = 2; p <= p_limit; p++) {
/* Find the optimal m and p divisors
   with minimal error +/- the required clock */
-   calc_dsi_clk = (m * ref_clk) / p;
+   calc_dsi_clk = (m * ref_clk) / (p * n_limit);
if (calc_dsi_clk == target_dsi_clk) {
calc_m = m;
calc_p = p;
@@ -212,11 +232,14 @@ static int dsi_calc_mnp(u32 dsi_clk, struct dsi_mnp 
*dsi_mnp)
}
 
m_seed = lfsr_converts[calc_m - 62];
-   n = 1;
+   n = n_limit;
dsi_mnp->dsi_pll_ctrl = 1 << (DSI_PLL_P1_POST_DIV_SHIFT + calc_p - 2);
-   dsi_mnp->dsi_pll_div = (n - 1) << DSI_PLL_N1_DIV_SHIFT |
-   m_seed << DSI_PLL_M1_DIV_SHIFT;
-
+   if (IS_CHERRYVIEW(dev_priv->dev))
+   dsi_mnp->dsi_pll_div = (n/2) << DSI_PLL_N1_DIV_SHIFT |
+   m_seed << DSI_PLL_M1_DIV_SHIFT;
+   else
+   dsi_mnp->dsi_pll_div = (n - 1) << DSI_PLL_N1_DIV_SHIFT |
+   m_seed << DSI_PLL_M1_DIV_SHIFT;
return 0;
 }
 
@@ -235,7 +258,7 @@ static void vlv_configure_dsi_pll(struct intel_encoder 
*encoder)
dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
intel_dsi->lane_count);
 
-   ret = dsi_calc_mnp(dsi_clk, &dsi_mnp);
+   ret = dsi_calc_mnp(dev_priv, dsi_clk, &dsi_mnp);
if (ret) {
DRM_DEBUG_KMS("dsi_calc_mnp failed\n");
return;
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH] drm/i915: Forcewake Register Range changes for CHV

[Ville Syrjälä]

On Thu, Dec 11, 2014 at 12:48:41PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S 
> 
> According to updated BSpec, Render/Common Wells register range changed.
> Updating the same to match the spec and avoid extra forcewake for none
> forcewake range.
> 
> Signed-off-by: Deepak S 
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 46de8d7..dd36f9b 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -647,9 +647,9 @@ void assert_force_wake_inactive(struct drm_i915_private 
> *dev_priv)
>  
>  #define FORCEWAKE_CHV_RENDER_RANGE_OFFSET(reg) \
>   (REG_RANGE((reg), 0x2000, 0x4000) || \
> -  REG_RANGE((reg), 0x5000, 0x8000) || \
> +  REG_RANGE((reg), 0x5200, 0x8000) || \
>REG_RANGE((reg), 0x8300, 0x8500) || \
> -  REG_RANGE((reg), 0xB000, 0xC000) || \
> +  REG_RANGE((reg), 0xB000, 0xB480) || \
>REG_RANGE((reg), 0xE000, 0xE800))
>  
>  #define FORCEWAKE_CHV_MEDIA_RANGE_OFFSET(reg) \
> @@ -665,10 +665,7 @@ void assert_force_wake_inactive(struct drm_i915_private 
> *dev_priv)
>REG_RANGE((reg), 0x8000, 0x8300) || \
>REG_RANGE((reg), 0x8500, 0x8600) || \
>REG_RANGE((reg), 0x9000, 0xB000) || \
> -  REG_RANGE((reg), 0xC000, 0xC800) || \
> -  REG_RANGE((reg), 0xF000, 0x1) || \
> -  REG_RANGE((reg), 0x14000, 0x14400) || \
> -  REG_RANGE((reg), 0x22000, 0x24000))
> +  REG_RANGE((reg), 0xF000, 0x1))

Looks correct.

It looks like the media offsets could use a small adjustment as well:
- REG_RANGE((reg), 0x3, 0x4)
+ REG_RANGE((reg), 0x3, 0x38000)

So with that changed 
Reviewed-by: Ville Syrjälä 

One thing I don't understand though; Why is the [0x10,0x18[ range
marked as GWK in the spreadsheet? That's where the forcewake req/ack
registers live as well as some other GTFIFO stuff etc. How can you take
forcewake if the forcewake req/ack itself would need forcewake. I think
this must be an error in the spreadsheet and that range should be GNW.

>  
>  #define FORCEWAKE_GEN9_UNCORE_RANGE_OFFSET(reg) \
>   REG_RANGE((reg), 0xB00,  0x2000)
> -- 
> 1.9.1

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

[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[Daniel Vetter]

Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.

We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.

The idea to use __builtin_constant_p is from Chris Wilson.

v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.

Also use a temporary variable to only evaluate the condition once,
suggested by Damien.

v3: It's crazy but apparently 32bit gcc can't compile out the
BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
why, but until clue grows just disable this nifty idea on 32bit
builds. Reported by 0-day builder.

v4: Got it all wrong, apparently its the gcc version. We need 4.9+.
Now reported by Imre.

Cc: Imre Deak 
Cc: Damien Lespiau 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Dave Gordon 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 13 -
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  6 +++---
 drivers/gpu/drm/i915/intel_display.c |  4 ++--
 drivers/gpu/drm/i915/intel_uncore.c  |  4 ++--
 5 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445eca9ce..f44a844a48db 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum 
intel_display_power_domain domain)
case POWER_DOMAIN_INIT:
return "INIT";
default:
-   WARN_ON(1);
+   MISSING_CASE();
return "?";
}
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95dfa2dd35b9..4532526deb5f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -58,7 +58,18 @@
 #define DRIVER_DATE"20141205"
 
 #undef WARN_ON
-#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
+/* Only 4.9+ gcc can compile away the BUILD_BUG_ON correctly. */
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9)
+#define WARN_ON(x) ({ \
+   bool __i915_warn_cond = (x); \
+   if (__builtin_constant_p(__i915_warn_cond)) \
+   BUILD_BUG_ON(__i915_warn_cond); \
+   WARN(__i915_warn_cond, "WARN_ON(" #x ")"); })
+#else
+#define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")
+#endif
+
+#define MISSING_CASE() WARN(1, "Missing switch case in %s\n", __func__);
 
 enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ac03a382000b..3b5807c11427 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
}
 
return pte;
@@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
}
 
return pte;
@@ -1146,7 +1146,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 8)
gen8_ppgtt_enable(dev);
else
-   WARN_ON(1);
+   MISSING_CASE();
 
if (ppgtt) {
for_each_ring(ring, dev_priv, i) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d5153a4f90fe..b7155d5efc10 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4847,7 +4847,7 @@ static void cherryview_set_cdclk(struct drm_device *dev, 
int cdclk)
cmd = 0;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
return;
}
 
@@ -8224,7 +8224,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE();
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d75b4bf..83ab530fee06 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1202,7 +1202

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove '& 0xffff' from the mask given to WA_REG()

[Jani Nikula]

On Mon, 08 Dec 2014, Damien Lespiau  wrote:
> We may be hidding bugs by doing that, so let remove it and have the
> actual mask value shine through, for better or worse.
>
> Signed-off-by: Damien Lespiau 

Pushed these two to drm-intel-next-fixes, thanks for the patches.

BR,
Jani.



> ---
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 4f63c39..c715ef0 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -734,10 +734,10 @@ static int wa_add(struct drm_i915_private *dev_priv,
>   }
>  
>  #define WA_SET_BIT_MASKED(addr, mask) \
> - WA_REG(addr, (mask) & 0x, _MASKED_BIT_ENABLE(mask))
> + WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
>  
>  #define WA_CLR_BIT_MASKED(addr, mask) \
> - WA_REG(addr, (mask) & 0x, _MASKED_BIT_DISABLE(mask))
> + WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
>  
>  #define WA_SET_FIELD_MASKED(addr, mask, value) \
>   WA_REG(addr, mask, _MASKED_FIELD(mask, value))
> -- 
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Protect against leaks in pipe_crc_set_source

[Ville Syrjälä]

On Wed, Dec 10, 2014 at 11:02:20AM +0100, Daniel Vetter wrote:
> Stupid userspace (there is no evil userspace in debugfs by assumption)
> might provoke a leak since we allocate the new array without holding
> any locks. Drop in an unconditional kfree to deal with this - kfree
> can handle NULL.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Daniel Vetter 

I thought we had some higher level protection in pipe_crc_set_source()
but indeed we don't. So yeah it can still race with itself, but no
longer leak with your fix.

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 72bb5aef9590..923e7575bb53 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3433,6 +3433,7 @@ static int pipe_crc_set_source(struct drm_device *dev, 
> enum pipe pipe,
>   hsw_disable_ips(crtc);
>  
>   spin_lock_irq(&pipe_crc->lock);
> + kfree(pipe_crc->entries);
>   pipe_crc->entries = entries;
>   pipe_crc->head = 0;
>   pipe_crc->tail = 0;
> -- 
> 2.1.1

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

[Intel-gfx] [PATCH i-g-t 1/4] Update README

[Thomas Wood]

Signed-off-by: Thomas Wood 
---
 README | 46 +-
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/README b/README
index 8bdaebd..f1aab58 100644
--- a/README
+++ b/README
@@ -1,17 +1,22 @@
-This is a collection of tools for development and testing of the Intel DRM
-driver.  There are many macro-level test suites that get used against our
-driver, including xtest, rendercheck, piglit, and oglconform, but failures
+Intel GPU Tools
+===
+
+Description
+---
+
+Intel GPU Tools is a collection of tools for development and testing of the
+Intel DRM driver. There are many macro-level test suites that get used against
+the driver, including xtest, rendercheck, piglit, and oglconform, but failures
 from those can be difficult to track down to kernel changes, and many require
 complicated build procedures or specific testing environments to get useful
-results.
+results. Therefore, Intel GPU Tools includes low-level tools and tests
+specifically for development and testing of the Intel DRM Driver.
 
-Thus, intel-graphics-tools was a project I started to collect some low-level
-tools I intended to build.
+Intel GPU Tools is split into several sections:
 
 benchmarks/
-   This should be a collection of useful microbenchmarks.  The hope is
-   that people can use these to tune some pieces of DRM code in relevant
-   ways.
+   This is a collection of useful microbenchmarks that can be used to tune
+   DRM code in relevant ways.
 
The benchmarks require KMS to be enabled.  When run with an X Server
running, they must be run as root to avoid the authentication
@@ -21,8 +26,11 @@ benchmarks/
 
 tests/
This is a set of automated tests to run against the DRM to validate
-   changes.  Hopefully this can cover the relevant cases we need to
-   worry about, including backwards compatibility.
+   changes. Many of the tests have subtests, which can be listed by using
+   the --list-subtests command line option and then run using the
+   --run-subtest option. If --run-subtest is not used, all subtests will
+   be run. Some tests have futher options and these are detailed by using
+   the --help option.
 
The test suite can be run using the run-tests.sh script available in
the scripts directory. Piglit is used to run the tests and can either
@@ -115,9 +123,10 @@ debugger/
The debugger must be run as root: "sudo debugger/eudb"
 
 docs/
-   Thus far just contains the autogenerated intel-gpu-tools libraries
-   reference documenation in docs/reference/ You need to have the gtk doc
-   tools installed to generate this API documentation.
+   Contains the automatically generated intel-gpu-tools libraries
+   reference documentation in docs/reference/. You need to have the
+   gtk-doc tools installed and use the "--enable-gtk-doc" configure flag
+   to generate this API documentation.
 
To regenerate the html files when updating documentation, use:
 
@@ -128,9 +137,12 @@ docs/
intel-gpu-tools-sections.txt. Entirely new sections will also need to be
added to intel-gpu-tools-docs.xml in the appropriate place.
 
-DEPENDENCIES
-   This is a non-exchaustive list of package dependencies required for
-   building everything:
+
+Requirements
+
+
+This is a non-exhaustive list of package dependencies required for
+building everything:
 
libpciaccess-dev
libdrm-dev
-- 
2.1.0

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

[Intel-gfx] [PATCH i-g-t 2/4] Add a MAINTAINERS file

[Thomas Wood]

Signed-off-by: Thomas Wood 
---
 CONTRIBUTING | 9 +++--
 MAINTAINERS  | 2 ++
 2 files changed, 5 insertions(+), 6 deletions(-)
 create mode 100644 MAINTAINERS

diff --git a/CONTRIBUTING b/CONTRIBUTING
index 0ad0c3a..a2ddf09 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -33,12 +33,9 @@ A short list of contribution guidelines:
 
 - When patches from new contributors (without commit access) are stuck, for
   anything related to the regular releases, issues with packaging and
-  integrating platform support or anything else really please contact the i-g-t
-  maintainer:
-
-Thomas Wood 
-
-  Of course please also cc the intel-gfx mailing list.
+  integrating platform support or any other intel-gpu-tools issues, please
+  contact one of the maintainers (listed in the MAINTAIENRS file) and cc the
+  intel-gfx mailing list.
 
 - Especially changes to the testcase should get tested on relevant platforms
   before committing. For Intel employees that's best done using PRTS, see the
diff --git a/MAINTAINERS b/MAINTAINERS
new file mode 100644
index 000..7825e1e
--- /dev/null
+++ b/MAINTAINERS
@@ -0,0 +1,2 @@
+Daniel Vetter 
+Thomas Wood 
-- 
2.1.0

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

[Intel-gfx] [PATCH i-g-t 4/4] tools: add missing copyright headers

[Thomas Wood]

Signed-off-by: Thomas Wood 
---
 tools/ddi_compute_wrpll.c | 23 +++
 tools/intel_l3_udev_listener.c| 23 +++
 tools/quick_dump/chipset_macro_wrap.c | 23 +++
 tools/skl_ddb_allocation.c| 23 +++
 4 files changed, 92 insertions(+)

diff --git a/tools/ddi_compute_wrpll.c b/tools/ddi_compute_wrpll.c
index 45c28e1..e27cc34 100644
--- a/tools/ddi_compute_wrpll.c
+++ b/tools/ddi_compute_wrpll.c
@@ -1,3 +1,26 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
 #include 
 #include 
 #include 
diff --git a/tools/intel_l3_udev_listener.c b/tools/intel_l3_udev_listener.c
index c50820c..261630e 100644
--- a/tools/intel_l3_udev_listener.c
+++ b/tools/intel_l3_udev_listener.c
@@ -1,3 +1,26 @@
+/*
+ * Copyright © 2013 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.
+ */
+
 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
diff --git a/tools/quick_dump/chipset_macro_wrap.c 
b/tools/quick_dump/chipset_macro_wrap.c
index 7b67340..fa568d6 100644
--- a/tools/quick_dump/chipset_macro_wrap.c
+++ b/tools/quick_dump/chipset_macro_wrap.c
@@ -1,3 +1,26 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
 #include 
 #include 
 #include 
diff --git a/tools/skl_ddb_allocation.c b/tools/skl_ddb_allocation.c
index 4d8e6d1..c7bfb27 100644
--- a/tools/skl_ddb_allocation.c
+++ b/tools/skl_ddb_allocation.c
@@ -1,3 +1,26 @@
+/*
+ * Copyright © 2014 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

[Intel-gfx] [PATCH i-g-t 3/4] NEWS: Updates

[Thomas Wood]

Signed-off-by: Thomas Wood 
---
 NEWS | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/NEWS b/NEWS
index 103c7cd..447ba77 100644
--- a/NEWS
+++ b/NEWS
@@ -1,18 +1,30 @@
 Release 1.9 (-XX-XX)
 
 
-- As usual piles of new testcases and improvements to existing ones.
+- New test cases added: drm_import_export, gem_gpgpu_fill, gem_ppgtt,
+  gem_tiled_wb, kms_pwrite_crc.
 
 - New helper for interactive progress indicators (see igt_print_activity and
   igt_progress), which can be disabled by setting the log-level to warn (Thomas
   and Daniel).
 
-- Basic skl support: pci ids, rendercpy&mediafill (Damien, Zhao Yakui).
+- Basic skl support: pci ids, rendercopy & mediafill (Damien, Zhao Yakui).
 
 - chv support for the iosf sideband tools and a few other improvements (Ville).
 
 - Fence register support for intel_reg_dumper on bdw+ (Rodrigo).
 
+- Support for skl in quick_dump (Damien).
+
+- Golden state generation infrastructure (Mika).
+
+- New skl watermark tool (Damien).
+
+- New EDID test block that includes multiple display modes (Thomas).
+
+- Individual test documentation available in generated documentation and from
+  the test binaries (Thomas).
+
 Release 1.8 (2014-09-08)
 
 
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Quietly reject attempts to create non-pagealigned stolen objects

[Ville Syrjälä]

On Wed, Dec 10, 2014 at 02:53:01PM +0100, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 11:13:28AM +, Chris Wilson wrote:
> > On Wed, Dec 10, 2014 at 11:23:44AM +0100, Daniel Vetter wrote:
> > > On Wed, Dec 10, 2014 at 08:17:11AM +, Chris Wilson wrote:
> > > > This added as a BUG_ON as it considered that no one would ever request
> > > > an unaligned object. However, it turns out that some BIOSes will
> > > > allocate a scanout that is offset from 0 and not aligned to a page
> > > > boundary, and we were passing this through and hitting the BUG_ON during
> > > > boot.
> > > > 
> > > > Quietly reject such a request to reserve the unaligned stolen object and
> > > > let the boot continue, restoring previous behaviour (i.e. no BIOS
> > > > framebuffer preservation).
> > > > 
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: sta...@vger.kernel.org
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_gem_stolen.c | 10 ++
> > > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> > > > b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > > index 5c616ec2c5c8..a3bc0fa07c6c 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> > > > @@ -646,13 +646,15 @@ 
> > > > i915_gem_object_create_stolen_for_preallocated(struct drm_device *dev,
> > > > DRM_DEBUG_KMS("creating preallocated stolen object: 
> > > > stolen_offset=%x, gtt_offset=%x, size=%x\n",
> > > > stolen_offset, gtt_offset, size);
> > > >  
> > > > -   /* KISS and expect everything to be page-aligned */
> > > > -   BUG_ON(stolen_offset & 4095);
> > > > -   BUG_ON(size & 4095);
> > > > -
> > > > if (WARN_ON(size == 0))
> > > > return NULL;
> > > >  
> > > > +   /* KISS and expect everything to be GTT page-aligned */
> > > > +   if ((stolen_offset | size) & 4095) {
> > > 
> > > Imo we should stil WARN_ON and fixup up the takeover code to align things
> > > properly ...
> > 
> > You shot down my idea for storing deltas into objects in the past...
> > 
> > The BIOS scanout is properly aligned to the rules of the display engine,
> > just not according to our mm restrictions. The bigger question is
> > whether our 1:1 offset-to-stolen mapping is correct. It could well be
> > that that the framebuffer is at stolen address 0, but just has a GTT
> > offset.
> > 
> > So the only question is whether we reject the object reservation at the
> > stolen layer or at the plane config layer. I decided that stolen was
> > better, because it is failing to meet our mm restrictions not
> > hardware restrictions.
> 
> The framebuffer layer can very much cope with offsets, so no need to
> reject it. We just need to patch up the framebuffer we create a bit.
> Offsets are in pixels but that should align well.

Or someone can dig out my old fb->offsets[] handling patch (and double check
that it's sane, fixing if not).

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

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Add WaForceEnableNonCoherent label

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK -5  364/366  359/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt_kms_render_direct-render  PASS(5, M26)  DMESG_WARN(1, M26)
*ILK  igt_kms_flip_bcs-flip-vs-modeset-interruptible  PASS(4, M26)  
DMESG_WARN(1, M26)
*ILK  igt_kms_flip_flip-vs-panning  PASS(6, M26)  DMESG_WARN(1, M26)
*ILK  igt_kms_flip_flip-vs-rmfb-interruptible  NSPT(1, M26)PASS(3, M26) 
 DMESG_WARN(1, M26)
*ILK  igt_kms_flip_rcs-flip-vs-panning  PASS(4, M26)  NSPT(1, M26)
*ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(2, M26)PASS(14, M26M37)   
   NSPT(1, M26)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Track nested calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

With the current deferred-submission model, if a problem arises part-way
through the insertion of instructions into the ringbuffer (e.g. due to
one of the begin() calls finding there's not enough space), we avoid
sending the incomplete sequence to the h/w; but currently have no means
of undoing the work so far, which will lead to undefined behaviour when
the next batch is submitted (probably TDR will trigger a reset first,
though, and clean up the ring state).

A future idea is to move to an atomic-submission model, where all the
space required for a batch submission is reserved up front, and in the
event of failure partway through, the work can be abandoned without
side-effects. This will be required for the forthcoming GPU scheduler
(specifically, for preemption).

To support this, we allow nested begin/advance pairs.  Specifically,
the outermost pair defines the total space reservation; inner pairs
can be nested ad lib, but all inner reservations at any level must
fit entirely within the outermost one.  Thus, this is permitted:

begin(128) - guarantees that up to 128 dwords can now be
emitted without waiting for more freespace
begin(6)
advance
begin(10)
advance
begin(8)
advance
etc, as long as the total is no more than 128 dwords
advance-and-submit

The execbuffer code will later be enhanced to use this approach. In the
mean time, the traditional single-level begin/advance mechanism remains
fully supported.

This commit changes only the begin/advance checking code, to permit (but
not require) nested begin/advance pairs.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_ringbuffer.h |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a10d271..71cb3ef 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -416,8 +416,17 @@ static inline void __intel_ringbuffer_begin(struct 
intel_ringbuffer *ringbuf,
WARN_ON(nbytes <= 0);
 
if (ringbuf->rsv_level++) {
-   /* begin() called twice or more without advance() */
-   WARN_ON(1);
+   /*
+* A nested reservation; check that it falls entirely
+* within the outer block. Don't adjust remaining space.
+*/
+   WARN_ON(ringbuf->rsv_start < 0);
+   WARN_ON(ringbuf->rsv_start & 7);
+   WARN_ON(ringbuf->tail & 7);
+   WARN_ON(ringbuf->tail > ringbuf->effective_size);
+   WARN_ON(ringbuf->tail > ringbuf->rsv_start + ringbuf->rsv_size);
+   WARN_ON(ringbuf->tail + nbytes > ringbuf->effective_size);
+   WARN_ON(ringbuf->tail + nbytes > ringbuf->rsv_start + 
ringbuf->rsv_size);
} else {
/*
 * A new reservation; validate and record the start and
@@ -437,7 +446,7 @@ static inline void __intel_ringbuffer_begin(struct 
intel_ringbuffer *ringbuf,
 static inline void __intel_ringbuffer_check(struct intel_ringbuffer *ringbuf)
 {
 #if1
-   WARN_ON(ringbuf->rsv_level-- != 1);
+   WARN_ON(ringbuf->rsv_level-- <= 0);
WARN_ON(ringbuf->rsv_start < 0 || ringbuf->rsv_size < 0);
WARN_ON(ringbuf->tail & 7);
WARN_ON(ringbuf->tail > ringbuf->rsv_start + ringbuf->rsv_size);
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 0/2] Track calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance().  Historically some (display) code
didn't use begin/advance, but just inserted instructions ad hoc, which
would then be sent to the hardware along with the current or next batch,
but this is not supported and is now regarded as incorrect.

This commit therefore adds begin/advance tracking, with WARNings where
various forms of misuse are detected.

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

[Intel-gfx] [PATCH 1/2] drm/i915: Track & check calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance() (note that this used to trigger
immediate submission to the h/w, but now actual submission is deferred
until all the instructions for a single batch submission have been
assembled). Historically some (display) code didn't use begin/advance,
but just inserted instructions ad hoc, which would then be sent to the
hardware along with the current or next batch, but this is not supported
and is now regarded as incorrect.

This commit therefore adds begin/advance tracking, with WARNings where
various forms of misuse are detected. These include:
* advance without begin
* begin without advance before submission to h/w
* multiple begins without an advance between
* exceeding the space reserved by begin
* leaving the ring misaligned
* ring buffer overrun (negative freespace)

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_lrc.c|4 ++-
 drivers/gpu/drm/i915/intel_lrc.h|   11 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |   10 --
 drivers/gpu/drm/i915/intel_ringbuffer.h |   55 ++-
 4 files changed, 75 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a82020e..56e3636 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -825,6 +825,7 @@ void intel_logical_ring_advance_and_submit(struct 
intel_ringbuffer *ringbuf)
struct intel_context *ctx = ringbuf->FIXME_lrc_ctx;
 
intel_logical_ring_advance(ringbuf);
+   WARN_ON(ringbuf->rsv_level != 0);
 
if (intel_ring_stopped(ring))
return;
@@ -1084,7 +1085,8 @@ int intel_logical_ring_begin(struct intel_ringbuffer 
*ringbuf, int num_dwords)
if (ret)
return ret;
 
-   ringbuf->space -= num_dwords * sizeof(uint32_t);
+   __intel_ringbuffer_begin(ringbuf, num_dwords);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 14b216b..9a0457e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -48,8 +48,17 @@ void intel_logical_ring_advance_and_submit(struct 
intel_ringbuffer *ringbuf);
  */
 static inline void intel_logical_ring_advance(struct intel_ringbuffer *ringbuf)
 {
-   ringbuf->tail &= ringbuf->size - 1;
+   __intel_ringbuffer_check(ringbuf);
+
+   /*
+* Tail == effecive_size is legitimate (buffer exactly full).
+* Tail > effective_size is not, and should give a warning,
+* but we'll reset tail in both cases to prevent further chaos
+*/
+   if (ringbuf->tail >= ringbuf->effective_size)
+   ringbuf->tail -= ringbuf->effective_size;
 }
+
 /**
  * intel_logical_ring_emit() - write a DWORD to the ringbuffer.
  * @ringbuf: Ringbuffer to write to.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 83accb7..5874eab 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -55,6 +55,7 @@ int __intel_ring_space(int head, int tail, int size)
int space = head - tail;
if (space <= 0)
space += size;
+   WARN_ON(space < I915_RING_FREE_SPACE);
return space - I915_RING_FREE_SPACE;
 }
 
@@ -84,7 +85,10 @@ bool intel_ring_stopped(struct intel_engine_cs *ring)
 void __intel_ring_advance(struct intel_engine_cs *ring)
 {
struct intel_ringbuffer *ringbuf = ring->buffer;
-   ringbuf->tail &= ringbuf->size - 1;
+
+   intel_ring_advance(ring);
+   WARN_ON(ringbuf->rsv_level != 0);
+
if (intel_ring_stopped(ring))
return;
ring->write_tail(ring, ringbuf->tail);
@@ -1911,6 +1915,7 @@ static int intel_ring_wait_request(struct intel_engine_cs 
*ring, int n)
return 0;
 
list_for_each_entry(request, &ring->request_list, list) {
+   /* Would completion of this request free enough space? */
if (__intel_ring_space(request->tail, ringbuf->tail,
   ringbuf->size) >= n) {
break;
@@ -2096,7 +2101,8 @@ int intel_ring_begin(struct intel_engine_cs *ring,
if (ret)
return ret;
 
-   ring->buffer->space -= num_dwords * sizeof(uint32_t);
+   __intel_ringbuffer_begin(ring->buffer, num_dwords);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 6dbb6f4..a10d271 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -112,6 +112,11 @@ struct intel_ringbuffer {
int size;
int effective_size;
 
+   /* these let advance() chec

Re: [Intel-gfx] [PATCH] drm/i915: Quietly reject attempts to create non-pagealigned stolen objects

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1 364/366  365/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(2, M26)PASS(15, M26M37)   
   PASS(1, M37)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/4] Add a MAINTAINERS file

[Jani Nikula]

On Wed, 10 Dec 2014, Thomas Wood  wrote:
> Signed-off-by: Thomas Wood 
> ---
>  CONTRIBUTING | 9 +++--
>  MAINTAINERS  | 2 ++
>  2 files changed, 5 insertions(+), 6 deletions(-)
>  create mode 100644 MAINTAINERS
>
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> index 0ad0c3a..a2ddf09 100644
> --- a/CONTRIBUTING
> +++ b/CONTRIBUTING
> @@ -33,12 +33,9 @@ A short list of contribution guidelines:
>  
>  - When patches from new contributors (without commit access) are stuck, for
>anything related to the regular releases, issues with packaging and
> -  integrating platform support or anything else really please contact the 
> i-g-t
> -  maintainer:
> -
> -Thomas Wood 
> -
> -  Of course please also cc the intel-gfx mailing list.
> +  integrating platform support or any other intel-gpu-tools issues, please
> +  contact one of the maintainers (listed in the MAINTAIENRS file) and cc the

You forgot to git mv MAINTAINERS MAINTAIENRS ;)

Jani.

> +  intel-gfx mailing list.
>  
>  - Especially changes to the testcase should get tested on relevant platforms
>before committing. For Intel employees that's best done using PRTS, see the
> diff --git a/MAINTAINERS b/MAINTAINERS
> new file mode 100644
> index 000..7825e1e
> --- /dev/null
> +++ b/MAINTAINERS
> @@ -0,0 +1,2 @@
> +Daniel Vetter 
> +Thomas Wood 
> -- 
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Track & check calls to intel(_logical)_ring_{begin, advance}

[Daniel Vetter]

On Wed, Dec 10, 2014 at 03:07:08PM +, Dave Gordon wrote:
> @@ -401,11 +406,59 @@ static inline void intel_ring_emit(struct 
> intel_engine_cs *ring,
>   iowrite32(data, ringbuf->virtual_start + ringbuf->tail);
>   ringbuf->tail += 4;
>  }
> +
> +static inline void __intel_ringbuffer_begin(struct intel_ringbuffer *ringbuf,
> + int num_dwords)
> +{
> + int nbytes = num_dwords * sizeof(uint32_t);
> +#if  1   /* DEBUG CODE */

No #ifdef's in code please, they tend to be either just go stale or just
obfuscate the code.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Specify bsd rings through exec flag

[Dave Gordon]

On 10/12/14 09:11, Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 02:18:15AM +, Gong, Zhipeng wrote:
>> On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
>>> On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:

[snip]

 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 index e1ed85a..d9081ec 100644
 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 @@ -1273,8 +1273,23 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
 *data,
   else if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
   if (HAS_BSD2(dev)) {
   int ring_id;
 - ring_id = gen8_dispatch_bsd_ring(dev, file);
 - ring = &dev_priv->ring[ring_id];
 +
 + switch (args->flags & I915_EXEC_BSD_MASK) {
 + case I915_EXEC_BSD_DEFAULT:
 + ring_id = gen8_dispatch_bsd_ring(dev, file);
 + ring = &dev_priv->ring[ring_id];
 + break;
 + case I915_EXEC_BSD_RING1:
 + ring = &dev_priv->ring[VCS];
>>>
>>> Do we have any use-case for selecting ring1 specifically? I've thought
>>> it's only ring2 that is special?
>> The HEVC GPU commands should be dispatched to BSD RING 1 instead of BSD
>> RING2 as the two rings are asymmetrical. 
>> For the H264 decoding/encoding either ring is OK.
> 
> Well then same arguments applies with ring2 since only ring1 is special?
> It's just to minimize abi and reduce the amount of rope we hand to
> userspace.

Anyone who knows to use any of these flags is taking responsibility for
doing explicit engine allocation, so why not give them all the options
-- if for no other reason, more symmetry is good.

As an examle, there could be a case where userspace knows better than
the kernel how long each batch will take, and can predict an optimal
allocation pattern rather than just flip-flopping. So even when a batch
*can* run on either engine, there might be a reason to pick a specific one.

e.g.short-1 -> ring 1
short-2 -> ring 1
long-1  -> ring 2
short-3 -> ring 1
long-2  -> ring 1

because the program knows that the three short batches together will
take less time than the one first long one.

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

Re: [Intel-gfx] [PATCH] drm/i915: Forcewake Register Range changes for CHV

[Deepak S]

On Wednesday 10 December 2014 08:01 PM, Ville Syrjälä wrote:

On Thu, Dec 11, 2014 at 12:48:41PM +0530, deepa...@linux.intel.com wrote:

From: Deepak S 

According to updated BSpec, Render/Common Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.

Signed-off-by: Deepak S 
---
  drivers/gpu/drm/i915/intel_uncore.c | 9 +++--
  1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d7..dd36f9b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -647,9 +647,9 @@ void assert_force_wake_inactive(struct drm_i915_private 
*dev_priv)
  
  #define FORCEWAKE_CHV_RENDER_RANGE_OFFSET(reg) \

(REG_RANGE((reg), 0x2000, 0x4000) || \
-REG_RANGE((reg), 0x5000, 0x8000) || \
+REG_RANGE((reg), 0x5200, 0x8000) || \
 REG_RANGE((reg), 0x8300, 0x8500) || \
-REG_RANGE((reg), 0xB000, 0xC000) || \
+REG_RANGE((reg), 0xB000, 0xB480) || \
 REG_RANGE((reg), 0xE000, 0xE800))
  
  #define FORCEWAKE_CHV_MEDIA_RANGE_OFFSET(reg) \

@@ -665,10 +665,7 @@ void assert_force_wake_inactive(struct drm_i915_private 
*dev_priv)
 REG_RANGE((reg), 0x8000, 0x8300) || \
 REG_RANGE((reg), 0x8500, 0x8600) || \
 REG_RANGE((reg), 0x9000, 0xB000) || \
-REG_RANGE((reg), 0xC000, 0xC800) || \
-REG_RANGE((reg), 0xF000, 0x1) || \
-REG_RANGE((reg), 0x14000, 0x14400) || \
-REG_RANGE((reg), 0x22000, 0x24000))
+REG_RANGE((reg), 0xF000, 0x1))

Looks correct.

It looks like the media offsets could use a small adjustment as well:
- REG_RANGE((reg), 0x3, 0x4)
+ REG_RANGE((reg), 0x3, 0x38000)

So with that changed
Reviewed-by: Ville Syrjälä 


Thanks for reviewing...


One thing I don't understand though; Why is the [0x10,0x18[ range
marked as GWK in the spreadsheet? That's where the forcewake req/ack
registers live as well as some other GTFIFO stuff etc. How can you take
forcewake if the forcewake req/ack itself would need forcewake. I think
this must be an error in the spreadsheet and that range should be GNW.


I think [0x10,0x18] is already above the forecewake range [0x4]. We 
need request for a spec update.
It should be GNK


  
  #define FORCEWAKE_GEN9_UNCORE_RANGE_OFFSET(reg) \

REG_RANGE((reg), 0xB00,  0x2000)
--
1.9.1


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

[Intel-gfx] [PATCH v2] drm/i915: Forcewake Register Range changes for CHV

[deepak . s]

From: Deepak S 

According to updated BSpec, Render/Common/media Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.

v2: Update media forcewake range (Ville)

Signed-off-by: Deepak S 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_uncore.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 46de8d7..ffdd042 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -647,9 +647,9 @@ void assert_force_wake_inactive(struct drm_i915_private 
*dev_priv)
 
 #define FORCEWAKE_CHV_RENDER_RANGE_OFFSET(reg) \
(REG_RANGE((reg), 0x2000, 0x4000) || \
-REG_RANGE((reg), 0x5000, 0x8000) || \
+REG_RANGE((reg), 0x5200, 0x8000) || \
 REG_RANGE((reg), 0x8300, 0x8500) || \
-REG_RANGE((reg), 0xB000, 0xC000) || \
+REG_RANGE((reg), 0xB000, 0xB480) || \
 REG_RANGE((reg), 0xE000, 0xE800))
 
 #define FORCEWAKE_CHV_MEDIA_RANGE_OFFSET(reg) \
@@ -658,17 +658,14 @@ void assert_force_wake_inactive(struct drm_i915_private 
*dev_priv)
 REG_RANGE((reg), 0x12000, 0x14000) || \
 REG_RANGE((reg), 0x1A000, 0x1C000) || \
 REG_RANGE((reg), 0x1E800, 0x1EA00) || \
-REG_RANGE((reg), 0x3, 0x4))
+REG_RANGE((reg), 0x3, 0x38000))
 
 #define FORCEWAKE_CHV_COMMON_RANGE_OFFSET(reg) \
(REG_RANGE((reg), 0x4000, 0x5000) || \
 REG_RANGE((reg), 0x8000, 0x8300) || \
 REG_RANGE((reg), 0x8500, 0x8600) || \
 REG_RANGE((reg), 0x9000, 0xB000) || \
-REG_RANGE((reg), 0xC000, 0xC800) || \
-REG_RANGE((reg), 0xF000, 0x1) || \
-REG_RANGE((reg), 0x14000, 0x14400) || \
-REG_RANGE((reg), 0x22000, 0x24000))
+REG_RANGE((reg), 0xF000, 0x1))
 
 #define FORCEWAKE_GEN9_UNCORE_RANGE_OFFSET(reg) \
REG_RANGE((reg), 0xB00,  0x2000)
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 1/2] drm/i915: Track & check calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance() (note that this used to trigger
immediate submission to the h/w, but now actual submission is deferred
until all the instructions for a single batch submission have been
assembled). Historically some (display) code didn't use begin/advance,
but just inserted instructions ad hoc, which would then be sent to the
hardware along with the current or next batch, but this is not supported
and is now regarded as incorrect.

This commit therefore adds begin/advance tracking, with WARNings where
various forms of misuse are detected. These include:
* advance without begin
* begin without advance before submission to h/w
* multiple begins without an advance between
* exceeding the space reserved by begin
* leaving the ring misaligned
* ring buffer overrun (negative freespace)

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_lrc.c|4 ++-
 drivers/gpu/drm/i915/intel_lrc.h|   11 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c |   10 --
 drivers/gpu/drm/i915/intel_ringbuffer.h |   54 ++-
 4 files changed, 74 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a82020e..56e3636 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -825,6 +825,7 @@ void intel_logical_ring_advance_and_submit(struct 
intel_ringbuffer *ringbuf)
struct intel_context *ctx = ringbuf->FIXME_lrc_ctx;
 
intel_logical_ring_advance(ringbuf);
+   WARN_ON(ringbuf->rsv_level != 0);
 
if (intel_ring_stopped(ring))
return;
@@ -1084,7 +1085,8 @@ int intel_logical_ring_begin(struct intel_ringbuffer 
*ringbuf, int num_dwords)
if (ret)
return ret;
 
-   ringbuf->space -= num_dwords * sizeof(uint32_t);
+   __intel_ringbuffer_begin(ringbuf, num_dwords);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 14b216b..9a0457e 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -48,8 +48,17 @@ void intel_logical_ring_advance_and_submit(struct 
intel_ringbuffer *ringbuf);
  */
 static inline void intel_logical_ring_advance(struct intel_ringbuffer *ringbuf)
 {
-   ringbuf->tail &= ringbuf->size - 1;
+   __intel_ringbuffer_check(ringbuf);
+
+   /*
+* Tail == effecive_size is legitimate (buffer exactly full).
+* Tail > effective_size is not, and should give a warning,
+* but we'll reset tail in both cases to prevent further chaos
+*/
+   if (ringbuf->tail >= ringbuf->effective_size)
+   ringbuf->tail -= ringbuf->effective_size;
 }
+
 /**
  * intel_logical_ring_emit() - write a DWORD to the ringbuffer.
  * @ringbuf: Ringbuffer to write to.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 83accb7..5874eab 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -55,6 +55,7 @@ int __intel_ring_space(int head, int tail, int size)
int space = head - tail;
if (space <= 0)
space += size;
+   WARN_ON(space < I915_RING_FREE_SPACE);
return space - I915_RING_FREE_SPACE;
 }
 
@@ -84,7 +85,10 @@ bool intel_ring_stopped(struct intel_engine_cs *ring)
 void __intel_ring_advance(struct intel_engine_cs *ring)
 {
struct intel_ringbuffer *ringbuf = ring->buffer;
-   ringbuf->tail &= ringbuf->size - 1;
+
+   intel_ring_advance(ring);
+   WARN_ON(ringbuf->rsv_level != 0);
+
if (intel_ring_stopped(ring))
return;
ring->write_tail(ring, ringbuf->tail);
@@ -1911,6 +1915,7 @@ static int intel_ring_wait_request(struct intel_engine_cs 
*ring, int n)
return 0;
 
list_for_each_entry(request, &ring->request_list, list) {
+   /* Would completion of this request free enough space? */
if (__intel_ring_space(request->tail, ringbuf->tail,
   ringbuf->size) >= n) {
break;
@@ -2096,7 +2101,8 @@ int intel_ring_begin(struct intel_engine_cs *ring,
if (ret)
return ret;
 
-   ring->buffer->space -= num_dwords * sizeof(uint32_t);
+   __intel_ringbuffer_begin(ring->buffer, num_dwords);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 6dbb6f4..a6660c1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -112,6 +112,11 @@ struct intel_ringbuffer {
int size;
int effective_size;
 
+   /* these let advance() chec

[Intel-gfx] [PATCH v2 2/2] drm/i915: Track nested calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

With the current deferred-submission model, if a problem arises part-way
through the insertion of instructions into the ringbuffer (e.g. due to
one of the begin() calls finding there's not enough space), we avoid
sending the incomplete sequence to the h/w; but currently have no means
of undoing the work so far, which will lead to undefined behaviour when
the next batch is submitted (probably TDR will trigger a reset first,
though, and clean up the ring state).

A future idea is to move to an atomic-submission model, where all the
space required for a batch submission is reserved up front, and in the
event of failure partway through, the work can be abandoned without
side-effects. This will be required for the forthcoming GPU scheduler
(specifically, for preemption).

To support this, we allow nested begin/advance pairs.  Specifically,
the outermost pair defines the total space reservation; inner pairs
can be nested ad lib, but all inner reservations at any level must
fit entirely within the outermost one.  Thus, this is permitted:

begin(128) - guarantees that up to 128 dwords can now be
emitted without waiting for more freespace
begin(6)
advance
begin(10)
advance
begin(8)
advance
etc, as long as the total is no more than 128 dwords
advance-and-submit

The execbuffer code will later be enhanced to use this approach. In the
mean time, the traditional single-level begin/advance mechanism remains
fully supported.

This commit changes only the begin/advance checking code, to permit (but
not require) nested begin/advance pairs.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_ringbuffer.h |   15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index a6660c1..68665c7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -416,8 +416,17 @@ static inline void __intel_ringbuffer_begin(struct 
intel_ringbuffer *ringbuf,
WARN_ON(nbytes <= 0);
 
if (ringbuf->rsv_level++) {
-   /* begin() called twice or more without advance() */
-   WARN_ON(1);
+   /*
+* A nested reservation; check that it falls entirely
+* within the outer block. Don't adjust remaining space.
+*/
+   WARN_ON(ringbuf->rsv_start < 0);
+   WARN_ON(ringbuf->rsv_start & 7);
+   WARN_ON(ringbuf->tail & 7);
+   WARN_ON(ringbuf->tail > ringbuf->effective_size);
+   WARN_ON(ringbuf->tail > ringbuf->rsv_start + ringbuf->rsv_size);
+   WARN_ON(ringbuf->tail + nbytes > ringbuf->effective_size);
+   WARN_ON(ringbuf->tail + nbytes > ringbuf->rsv_start + 
ringbuf->rsv_size);
} else {
/*
 * A new reservation; validate and record the start and
@@ -436,7 +445,7 @@ static inline void __intel_ringbuffer_begin(struct 
intel_ringbuffer *ringbuf,
 
 static inline void __intel_ringbuffer_check(struct intel_ringbuffer *ringbuf)
 {
-   WARN_ON(ringbuf->rsv_level-- != 1);
+   WARN_ON(ringbuf->rsv_level-- <= 0);
WARN_ON(ringbuf->rsv_start < 0 || ringbuf->rsv_size < 0);
WARN_ON(ringbuf->tail & 7);
WARN_ON(ringbuf->tail > ringbuf->rsv_start + ringbuf->rsv_size);
-- 
1.7.9.5

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

[Intel-gfx] [PATCH v2 0/2] Track calls to intel(_logical)_ring_{begin, advance}

[Dave Gordon]

When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance().  Historically some (display) code
didn't use begin/advance, but just inserted instructions ad hoc, which
would then be sent to the hardware along with the current or next batch,
but this is not supported and is now regarded as incorrect.

This commit therefore adds begin/advance tracking, with WARNings where
various forms of misuse are detected.

v2: remove redundant "#if 1" markers

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

Re: [Intel-gfx] [PATCH 0/2] Track calls to intel(_logical)_ring_{begin, advance}

[Chris Wilson]

On Wed, Dec 10, 2014 at 03:07:07PM +, Dave Gordon wrote:
> When adding instructions to a legacy or LRC ringbuffer, the sequence of
> emit() calls must be preceded by a call to intel(_logical)_ring_begin()
> to reserve the required amount of space, and followed by a matching call
> to intel(_logical)_ring_advance().  Historically some (display) code
> didn't use begin/advance, but just inserted instructions ad hoc, which
> would then be sent to the hardware along with the current or next batch,
> but this is not supported and is now regarded as incorrect.
> 
> This commit therefore adds begin/advance tracking, with WARNings where
> various forms of misuse are detected.

Please review the suggested approach I made months ago which avoid all
this ad hoc hilarity.
-Chris

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request

[Daniel Vetter]

On Wed, Nov 12, 2014 at 12:13:03PM +, Nick Hoath wrote:
> On 12/11/2014 11:24, Chris Wilson wrote:
> >On Wed, Nov 12, 2014 at 10:53:26AM +, Nick Hoath wrote:
> > seq_putc(m, '\n');
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index afa9c35..0fe238c 100644
> >>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>@@ -2027,6 +2027,28 @@ struct drm_i915_gem_request {
> >>struct list_head free_list;
> >>
> >>uint32_t uniq;
> >>+
> >>+   /**
> >>+* The ELSP only accepts two elements at a time, so we queue 
> >>context/tail
> >>+* pairs on a given queue (ring->execlist_queue) until the hardware is
> >>+* available. The queue serves a double purpose: we also use it to keep 
> >>track
> >>+* of the up to 2 contexts currently in the hardware (usually one in 
> >>execution
> >>+* and the other queued up by the GPU): We only remove elements from 
> >>the head
> >>+* of the queue when the hardware informs us that an element has been
> >>+* completed.
> >>+*
> >>+* All accesses to the queue are mediated by a spinlock 
> >>(ring->execlist_lock).
> >>+*/
> >>+
> >>+   /** Execlist link in the submission queue.*/
> >>+   struct list_head execlist_link;
> >
> >This is redundant. The request should only be one of the pending or active
> >lists at any time.
> >
> This is used by the pending execlist requests list owned by the
> intel_engine_cs. The request isn't in both the active and pending execlist
> engine lists.

I guess we'll eventually need to subsume this into the scheduler's list of
ctxs. Or reuse it there. Imo ok for now, might just need a rename
longterm.

> >>+   /** Execlists workqueue for processing this request in a bottom half */
> >>+   struct work_struct work;
> >
> >For what purpose? This is not needed.
> This worker is currently used to free up execlist requests. This goes away
> when Thomas Daniel's patchset is merged.
> I have spotted a bug in the cleanup handler with the merged
> requests/execlists cleanup though.

I guess this will drop out on a rebase now that everything has landed?

> >>+   /** Execlists no. of times this request has been sent to the ELSP */
> >>+   int elsp_submitted;
> >
> >A request can only be submitted exactly once at any time. This
> >bookkeeping is not part of the request.
> This is a refcount to preserve the request if it has been resubmitted due to
> preemption or TDR, due to a race condition between the HW finishing with the
> item and the cleanup/resubmission. Have a look at
> e1fee72c2ea2e9c0c6e6743d32a6832f21337d6c which contains a much better
> description of why this exists.

Yeah this one is still a bit crazy but guess that's just how it is ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Untangle execlist tracking

[Daniel Vetter]

On Wed, Nov 12, 2014 at 10:53:22AM +, Nick Hoath wrote:
> This patchset merges execlist queue items in to gem requests. It does this by 
> using the reference count added by John Harrison's "Replace seqno values with
> request structures" patchset to ensure that the gem request is available for
> the whole execlist submission lifespan.
> 
> 
> v2: merge intel_ctx_submit_request and drm_i915_gem_request, rebase changes &
>add cover letter

Ok, sorry for the long delay - I got a bit distracted and also thought it
would be better to get John's and Thomas' patches in first since this is
based upon them.

But that's now out of the way and I think this is definitely a good step
into the right direction. So can you please rebase and resend so that we
can do the review&merge dance?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] intel mst + club 3d csv5300 hub only in clone mode + xorg crashes

[stephan schultchen]

hey,

i have a dell xps 13 with an integrated intel adapter running on kubuntu
14.10, and a club3d csv5300 displayport hub with two attached dell displays.

i am currently using the 3.18 kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/

the problem is that the displays attached to the DP hub only work in clone
mode.

and whenever i disconnect, or reconnect a display to the hub XOrg is
crashing with a segfault.

connecting and disconnecting the hub itself works fine.

here are the last lines of the xorg log:

[   310.480] (II) intel(0): resizing framebuffer to 3840x1200
[   310.485] (II) intel(0): switch to mode 1920x1080@60.0 on eDP1 using
pipe 0, position (0, 0), rotation normal, reflection none
[   310.516] (II) intel(0): switch to mode 1920x1080@60.0 on DP1 using pipe
1, position (0, 0), rotation normal, reflection none
[   310.524] (II) intel(0): switch to mode 1920x1200@60.0 on DP1 using pipe
1, position (1920, 0), rotation normal, reflection none
[   323.675] (II) intel(0): resizing framebuffer to 1920x1080
[   323.679] (II) intel(0): switch to mode 1920x1080@60.0 on eDP1 using
pipe 0, position (0, 0), rotation normal, reflection none
[   324.282] (II) intel(0): switch to mode 1920x1200@60.0 on DP1 using pipe
1, position (1920, 0), rotation normal, reflection none
[   324.808] (II) intel(0): switch to mode 1920x1080@60.0 on eDP1 using
pipe 0, position (0, 0), rotation normal, reflection none
[   324.808] (II) intel(0): switch to mode 1920x1200@60.0 on DP1 using pipe
1, position (1920, 0), rotation normal, reflection none
[   324.816] (II) intel(0): switch to mode 1920x1080@60.0 on eDP1 using
pipe 0, position (0, 0), rotation normal, reflection none
[   324.816] (II) intel(0): switch to mode 1920x1200@60.0 on DP1 using pipe
1, position (1920, 0), rotation normal, reflection none
[   324.832] (EE)
[   324.832] (EE) Backtrace:
[   324.832] (EE) 0: /usr/bin/X (xorg_backtrace+0x56) [0x7ff161614666]
[   324.832] (EE) 1: /usr/bin/X (0x7ff16145e000+0x1ba869) [0x7ff161618869]
[   324.832] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6
(0x7ff15f192000+0x36da0) [0x7ff15f1c8da0]
[   324.832] (EE) 3: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7ff15b58+0x69d85) [0x7ff15b5e9d85]
[   324.832] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7ff15b58+0x10be22) [0x7ff15b68be22]
[   324.832] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7ff15b58+0x6cb23) [0x7ff15b5ecb23]
[   324.832] (EE) 6: /usr/bin/X (WakeupHandler+0xaa) [0x7ff1614b9e2a]
[   324.832] (EE) 7: /usr/bin/X (WaitForSomething+0x1c7) [0x7ff161611a97]
[   324.832] (EE) 8: /usr/bin/X (0x7ff16145e000+0x56ec1) [0x7ff1614b4ec1]
[   324.832] (EE) 9: /usr/bin/X (0x7ff16145e000+0x5b2a6) [0x7ff1614b92a6]
[   324.832] (EE) 10: /lib/x86_64-linux-gnu/libc.so.6
(__libc_start_main+0xf5) [0x7ff15f1b3ec5]
[   324.832] (EE) 11: /usr/bin/X (0x7ff16145e000+0x456ae) [0x7ff1614a36ae]
[   324.832] (EE)
[   324.832] (EE) Segmentation fault at address 0x1e0
[   324.832] (EE)
Fatal server error:
[   324.832] (EE) Caught signal 11 (Segmentation fault). Server aborting
[   324.832] (EE)
[   324.832] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[   324.832] (EE) Please also check the log file at "/var/log/Xorg.0.log"
for additional information.
[   324.832] (EE)
[   324.832] (II) AIGLX: Suspending AIGLX clients for VT switch
[   326.124] (EE) Server terminated with error (1). Closing log file.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Jan Kiszka]

On 2014-12-04 03:24, Jike Song wrote:
> Hi all,
> 
>  We are pleased to announce the first release of KVMGT project. KVMGT is
> the implementation of Intel GVT-g technology, a full GPU virtualization
> solution. Under Intel GVT-g, a virtual GPU instance is maintained for
> each VM, with part of performance critical resources directly assigned.
> The capability of running native graphics driver inside a VM, without
> hypervisor intervention in performance critical paths, achieves a good
> balance of performance, feature, and sharing capability.
> 
> 
>  KVMGT is still in the early stage:
> 
>   - Basic functions of full GPU virtualization works, guest can see a
> full-featured vGPU.
> We ran several 3D workloads such as lightsmark, nexuiz, urbanterror
> and warsow.
> 
>   - Only Linux guest supported so far, and PPGTT must be disabled in
> guest through a
> kernel parameter(see README.kvmgt in QEMU).
> 
>   - This drop also includes some Xen specific changes, which will be
> cleaned up later.
> 
>   - Our end goal is to upstream both XenGT and KVMGT, which shares ~90%
> logic for vGPU
> device model (will be part of i915 driver), with only difference in
> hypervisor
> specific services
> 
>   - insufficient test coverage, so please bear with stability issues :)
> 
> 
> 
>  There are things need to be improved, esp. the KVM interfacing part:
> 
> 1a domid was added to each KVMGT guest
> 
> An ID is needed for foreground OS switching, e.g.
> 
> # echo >/sys/kernel/vgt/control/foreground_vm
> 
> domid 0 is reserved for host OS.
> 
> 
>  2SRCU workarounds.
> 
> Some KVM functions, such as:
> 
> kvm_io_bus_register_dev
> install_new_memslots
> 
> must be called *without* &kvm->srcu read-locked. Otherwise it
> hangs.
> 
> In KVMGT, we need to register an iodev only *after* BAR
> registers are
> written by guest. That means, we already have &kvm->srcu hold -
> trapping/emulating PIO(BAR registers) makes us in such a condition.
> That will make kvm_io_bus_register_dev hangs.
> 
> Currently we have to disable rcu_assign_pointer() in such
> functions.
> 
> These were dirty workarounds, your suggestions are high welcome!
> 
> 
> 3syscalls were called to access "/dev/mem" from kernel
> 
> An in-kernel memslot was added for aperture, but using syscalls
> like
> open and mmap to open and access the character device "/dev/mem",
> for pass-through.
> 
>  
> 
> 
> The source codes(kernel, qemu as well as seabios) are available at github:
> 
> git://github.com/01org/KVMGT-kernel
> git://github.com/01org/KVMGT-qemu
> git://github.com/01org/KVMGT-seabios
> 
> In the KVMGT-qemu repository, there is a "README.kvmgt" to be referred.
> 
> 
> 
> More information about Intel GVT-g and KVMGT can be found at:
> 
> 
> https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
> 
> 
> http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%20GPU%20Virtualization%20Solution_1.pdf
> 
> 
> 
> Appreciate your comments, BUG reports, and contributions!
> 

There is an even increasing interest to keep KVM's in-kernel guest
interface as small as possible, specifically for security reasons. I'm
sure there are some good performance reasons to create a new in-kernel
device model, but I suppose those will need good evidences why things
are done in the way they finally should be - and not via a user-space
device model. This is likely not a binary decision (all userspace vs. no
userspace), it is more about the size and robustness of the in-kernel
model vs. its performance.

One aspect could also be important: Are there hardware improvements in
sight that will eventually help to reduce the in-kernel device model and
make the overall design even more robust? How will those changes fit
best into a proposed user/kernel split?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two

[Dave Gordon]

On 10/12/14 10:58, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
>> From: John Harrison 
>>
>> The scheduler decouples the submission of batch buffers to the driver with 
>> their
>> submission to the hardware. This basically means splitting the execbuffer()
>> function in half. This change rearranges some code ready for the split to 
>> occur.
> 
> Now there's the curios question: Where will the split in top/bottom halves
> be? Without that I have no idea whether it makes sense and so can't review
> this patch. At least if the goal is to really prep for the scheduler and
> not just move a few lines around ;-)
> -Daniel
> 
[snip]
>>  
>> +i915_gem_execbuffer_move_to_active(vmas, ring);
>> +
>> +/* To be split into two functions here... */
>> +
>> +/* Unconditionally invalidate gpu caches and ensure that we do flush
>> + * any residual writes from the previous batch.
>> + */
>> +ret = logical_ring_invalidate_all_caches(ringbuf);

It'll be where the marker comment is above. Ahead of that point is stuff
to do with setting up software state; after that we're talking to h/w.
When the scheduler code goes it, it decouples the two by interposing at
this point. Then batches go into it with s/w state set up, but don't get
to talk to the h/w until they're selected for execution, possibly in a
different order.

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

Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for batch buffer pools

[Michael H. Nguyen]

Hi Jon,

On 12/10/2014 03:06 AM, Bloomfield, Jon wrote:

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Daniel Vetter
Sent: Tuesday, December 09, 2014 1:18 PM
To: Nguyen, Michael H
Cc: Brad Volkin; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for
batch buffer pools

On Mon, Dec 08, 2014 at 02:33:46PM -0800, michael.h.ngu...@intel.com
wrote:

From: Brad Volkin 

This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described in
the kerneldoc in the patch. The code is simple, but separating it out
makes it easier to change the underlying algorithms and to extend to
future use cases should they arise.

The interface is simple: init to create an empty pool, fini to clean
it up, get to obtain a new buffer. Note that all buffers are expected
to be inactive before cleaning up the pool.

Locking is currently based on the caller holding the struct_mutex.
We already do that in the places where we will use the batch pool for
the command parser.

v2:
- s/BUG_ON/WARN_ON/ for locking assertions
- Remove the cap on pool size
- Switch from alloc/free to init/fini

v3:
- Idiomatic looping structure in _fini
- Correct handling of purged objects
- Don't return a buffer that's too much larger than needed

v4:
- Rebased to latest -nightly

v5:
- Remove _put() function and clean up comments to match

v6:
- Move purged check inside the loop (danvet, from v4 1/7 feedback)

v7:
- Use single list instead of two. (Chris W)
- s/active_list/cache_list
- Squashed in debug patches (Chris W)
   drm/i915: Add a batch pool debugfs file

   It provides some useful information about the buffers in
   the global command parser batch pool.

   v2: rebase on global pool instead of per-ring pools
   v3: rebase

   drm/i915: Add batch pool details to i915_gem_objects debugfs

   To better account for the potentially large memory consumption
   of the batch pool.

Issue: VIZ-4719
Signed-off-by: Brad Volkin 
---
  Documentation/DocBook/drm.tmpl |   5 ++
  drivers/gpu/drm/i915/Makefile  |   1 +
  drivers/gpu/drm/i915/i915_debugfs.c|  71 ++--
  drivers/gpu/drm/i915/i915_drv.h|  21 +
  drivers/gpu/drm/i915/i915_gem.c|   1 +
  drivers/gpu/drm/i915/i915_gem_batch_pool.c | 132
+
  6 files changed, 222 insertions(+), 9 deletions(-)  create mode
100644 drivers/gpu/drm/i915/i915_gem_batch_pool.c

diff --git a/Documentation/DocBook/drm.tmpl
b/Documentation/DocBook/drm.tmpl index 85287cb..022923a 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4029,6 +4029,11 @@ int num_ioctls;
!Idrivers/gpu/drm/i915/i915_cmd_parser.c


+Batchbuffer Pools
+!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool
+!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c
+  
+  
  Logical Rings, Logical Ring Contexts and
Execlists  !Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings,
Logical Ring Contexts and Execlists
!Idrivers/gpu/drm/i915/intel_lrc.c
diff --git a/drivers/gpu/drm/i915/Makefile
b/drivers/gpu/drm/i915/Makefile index e4083e4..c8dbb37d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -19,6 +19,7 @@ i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o

  # GEM code
  i915-y += i915_cmd_parser.o \
+ i915_gem_batch_pool.o \
  i915_gem_context.o \
  i915_gem_render_state.o \
  i915_gem_debug.o \
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445e..3c3bf98 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -359,6 +359,33 @@ static int per_file_stats(int id, void *ptr, void

*data)

return 0;
  }

+#define print_file_stats(m, name, stats) \
+   seq_printf(m, "%s: %u objects, %zu bytes (%zu active, %zu inactive,

%zu global, %zu shared, %zu unbound)\n", \

+  name, \
+  stats.count, \
+  stats.total, \
+  stats.active, \
+  stats.inactive, \
+  stats.global, \
+  stats.shared, \
+  stats.unbound)


"print_file_stats" might be better named "print_obj_stats" or similar. As it 
stands
there is nothing in its name to suggest its purpose is to describe an object.
I guess the fnc name 'print_file_stats' was chosen b/c it takes a 
'stats' parameter of type 'struct file_stats' and prints the members. 
Seems fair to leave it I think as its generic.




+
+static void print_batch_pool_stats(struct seq_file *m,
+  struct drm_i915_private *dev_priv) {
+   struct drm_i915_gem_object *obj;
+   struct file_stats stats;
+
+   memset(&stats, 0, sizeof(stats));
+
+   list_for_each_entry(obj,
+   &de

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Updating assorted register and status page definitions

[Dave Gordon]

On 10/12/14 10:40, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:06PM +, john.c.harri...@intel.com wrote:
>> From: Dave Gordon 
>>
>> Added various definitions that will be useful for the scheduler in general 
>> and
>> pre-emptive context switching in particular.
>>
>> Change-Id: Ica805b94160426def51f5d520f5ce51c60864a98
>> For: VIZ-1587
>> Signed-off-by: Dave Gordon 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h |   30 ++-
>>  drivers/gpu/drm/i915/intel_ringbuffer.h |   40 
>> +--
>>  2 files changed, 67 insertions(+), 3 deletions(-)

[snip]

>> +/*
>> + * Tracking; these are updated by the GPU at the beginning and/or end of 
>> every
>> + * batch. One pair for regular buffers, the other for preemptive ones.
>> + */
>> +#define I915_BATCH_DONE_SEQNO   0x30  /* Completed batch seqno  
>>   */
>> +#define I915_BATCH_ACTIVE_SEQNO 0x31  /* In progress batch 
>> seqno  */
>> +#define I915_PREEMPTIVE_DONE_SEQNO  0x32  /* Completed preemptive batch   */
>> +#define I915_PREEMPTIVE_ACTIVE_SEQNO0x33  /* In progress preemptive 
>> batch */
> 
> This are software define and currently not yet used I think. Imo better to
> add them together with the scheduler code that uses them. Splitting out
> #define patches only makes sense if they can be reviewed separately (e.g.
> registers with Bspec). Just adding software stuff (structs, enums, offsets
> not enforced by hw) should be added with the actual code using it.

OK

>> +
>> +/*
>> + * Preemption; these are used by the GPU to save important registers
>> + */
>> +#define I915_SAVE_PREEMPTED_RING_PTR0x34  /* HEAD before preemption 
>> */
>> +#define I915_SAVE_PREEMPTED_BB_PTR  0x35  /* BB ptr before preemption   */
>> +#define I915_SAVE_PREEMPTED_SBB_PTR 0x36  /* SBB before preemption  */
>> +#define I915_SAVE_PREEMPTED_UHPTR   0x37  /* UHPTR after preemption */
>> +#define I915_SAVE_PREEMPTED_HEAD0x38  /* HEAD after preemption  */
>> +#define I915_SAVE_PREEMPTED_TAIL0x39  /* TAIL after preemption  */
>> +#define I915_SAVE_PREEMPTED_STATUS  0x3A  /* RS preemption status   */
>> +#define I915_SAVE_PREEMPTED_NOPID   0x3B  /* Dummy  */
> 
> I guess this is hardcoded in hw? In that case a HWS instead of I915 prefix
> sounds better to me to make it clear this is not something i915/gem code
> invented. Also comment should state whether this is execlist or gen8+ or
> something like that.
> -Daniel

No, these are s/w too, so they can be added later if that's preferred.

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

[Intel-gfx] [PATCH] drm/i915: Call the lrc irq handler correctly

[Daniel Vetter]

We consistently use the _irq_handler postfix for functions called in
hardirq context. Especially when it's a non-static function hardirq is
a crazy enough calling context to warrant this level of ocd. So rename
it.

Cc: Thomas Daniel 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_irq.c  | 10 +-
 drivers/gpu/drm/i915/intel_lrc.c |  4 ++--
 drivers/gpu/drm/i915/intel_lrc.h |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e6a1db36928e..e3dd2d62c992 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1385,14 +1385,14 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_device *dev,
if (rcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (rcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
 
bcs = tmp >> GEN8_BCS_IRQ_SHIFT;
ring = &dev_priv->ring[BCS];
if (bcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (bcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
} else
DRM_ERROR("The master control interrupt lied (GT0)!\n");
}
@@ -1408,14 +1408,14 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_device *dev,
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (vcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
 
vcs = tmp >> GEN8_VCS2_IRQ_SHIFT;
ring = &dev_priv->ring[VCS2];
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (vcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
} else
DRM_ERROR("The master control interrupt lied (GT1)!\n");
}
@@ -1442,7 +1442,7 @@ static irqreturn_t gen8_gt_irq_handler(struct drm_device 
*dev,
if (vcs & GT_RENDER_USER_INTERRUPT)
notify_ring(dev, ring);
if (vcs & GT_CONTEXT_SWITCH_INTERRUPT)
-   intel_execlists_handle_ctx_events(ring);
+   intel_lrc_irq_handler(ring);
} else
DRM_ERROR("The master control interrupt lied (GT3)!\n");
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index a82020ea9d0a..89b5577afe71 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -474,13 +474,13 @@ static bool execlists_check_remove_request(struct 
intel_engine_cs *ring,
 }
 
 /**
- * intel_execlists_handle_ctx_events() - handle Context Switch interrupts
+ * intel_lrc_irq_handler() - handle Context Switch interrupts
  * @ring: Engine Command Streamer to handle.
  *
  * Check the unread Context Status Buffers and manage the submission of new
  * contexts to the ELSP accordingly.
  */
-void intel_execlists_handle_ctx_events(struct intel_engine_cs *ring)
+void intel_lrc_irq_handler(struct intel_engine_cs *ring)
 {
struct drm_i915_private *dev_priv = ring->dev->dev_private;
u32 status_pointer;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index 14b216b9be7f..960fcbd2c98a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -112,7 +112,7 @@ struct intel_ctx_submit_request {
int elsp_submitted;
 };
 
-void intel_execlists_handle_ctx_events(struct intel_engine_cs *ring);
+void intel_lrc_irq_handler(struct intel_engine_cs *ring);
 void intel_execlists_retire_requests(struct intel_engine_cs *ring);
 
 #endif /* _INTEL_LRC_H_ */
-- 
2.1.3

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

Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for batch buffer pools

[Bloomfield, Jon]

> -Original Message-
> From: Nguyen, Michael H
> Sent: Wednesday, December 10, 2014 4:34 PM
> To: Bloomfield, Jon
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for
> batch buffer pools
> 
> Hi Jon,
> 
> On 12/10/2014 03:06 AM, Bloomfield, Jon wrote:
> >> -Original Message-
> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> >> Behalf Of Daniel Vetter
> >> Sent: Tuesday, December 09, 2014 1:18 PM
> >> To: Nguyen, Michael H
> >> Cc: Brad Volkin; intel-gfx@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a
> >> framework for batch buffer pools
> >>
> >> On Mon, Dec 08, 2014 at 02:33:46PM -0800, michael.h.ngu...@intel.com
> >> wrote:
> >>> From: Brad Volkin 
> >>>
> >>> This adds a small module for managing a pool of batch buffers.
> >>> The only current use case is for the command parser, as described in
> >>> the kerneldoc in the patch. The code is simple, but separating it
> >>> out makes it easier to change the underlying algorithms and to
> >>> extend to future use cases should they arise.
> >>>
> >>> The interface is simple: init to create an empty pool, fini to clean
> >>> it up, get to obtain a new buffer. Note that all buffers are
> >>> expected to be inactive before cleaning up the pool.
> >>>
> >>> Locking is currently based on the caller holding the struct_mutex.
> >>> We already do that in the places where we will use the batch pool
> >>> for the command parser.
> >>>
> >>> v2:
> >>> - s/BUG_ON/WARN_ON/ for locking assertions
> >>> - Remove the cap on pool size
> >>> - Switch from alloc/free to init/fini
> >>>
> >>> v3:
> >>> - Idiomatic looping structure in _fini
> >>> - Correct handling of purged objects
> >>> - Don't return a buffer that's too much larger than needed
> >>>
> >>> v4:
> >>> - Rebased to latest -nightly
> >>>
> >>> v5:
> >>> - Remove _put() function and clean up comments to match
> >>>
> >>> v6:
> >>> - Move purged check inside the loop (danvet, from v4 1/7 feedback)
> >>>
> >>> v7:
> >>> - Use single list instead of two. (Chris W)
> >>> - s/active_list/cache_list
> >>> - Squashed in debug patches (Chris W)
> >>>drm/i915: Add a batch pool debugfs file
> >>>
> >>>It provides some useful information about the buffers in
> >>>the global command parser batch pool.
> >>>
> >>>v2: rebase on global pool instead of per-ring pools
> >>>v3: rebase
> >>>
> >>>drm/i915: Add batch pool details to i915_gem_objects debugfs
> >>>
> >>>To better account for the potentially large memory consumption
> >>>of the batch pool.
> >>>
> >>> Issue: VIZ-4719
> >>> Signed-off-by: Brad Volkin 
> >>> ---
> >>>   Documentation/DocBook/drm.tmpl |   5 ++
> >>>   drivers/gpu/drm/i915/Makefile  |   1 +
> >>>   drivers/gpu/drm/i915/i915_debugfs.c|  71 ++--
> >>>   drivers/gpu/drm/i915/i915_drv.h|  21 +
> >>>   drivers/gpu/drm/i915/i915_gem.c|   1 +
> >>>   drivers/gpu/drm/i915/i915_gem_batch_pool.c | 132
> >>> +
> >>>   6 files changed, 222 insertions(+), 9 deletions(-)  create mode
> >>> 100644 drivers/gpu/drm/i915/i915_gem_batch_pool.c
> >>>
> >>> diff --git a/Documentation/DocBook/drm.tmpl
> >>> b/Documentation/DocBook/drm.tmpl index 85287cb..022923a 100644
> >>> --- a/Documentation/DocBook/drm.tmpl
> >>> +++ b/Documentation/DocBook/drm.tmpl
> >>> @@ -4029,6 +4029,11 @@ int num_ioctls;
> >>> !Idrivers/gpu/drm/i915/i915_cmd_parser.c
> >>> 
> >>> 
> >>> +Batchbuffer Pools
> >>> +!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool
> >>> +!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c
> >>> +  
> >>> +  
> >>>   Logical Rings, Logical Ring Contexts and
> >>> Execlists  !Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings,
> >>> Logical Ring Contexts and Execlists
> >>> !Idrivers/gpu/drm/i915/intel_lrc.c
> >>> diff --git a/drivers/gpu/drm/i915/Makefile
> >>> b/drivers/gpu/drm/i915/Makefile index e4083e4..c8dbb37d 100644
> >>> --- a/drivers/gpu/drm/i915/Makefile
> >>> +++ b/drivers/gpu/drm/i915/Makefile
> >>> @@ -19,6 +19,7 @@ i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
> >>>
> >>>   # GEM code
> >>>   i915-y += i915_cmd_parser.o \
> >>> +   i915_gem_batch_pool.o \
> >>> i915_gem_context.o \
> >>> i915_gem_render_state.o \
> >>> i915_gem_debug.o \
> >>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> >>> b/drivers/gpu/drm/i915/i915_debugfs.c
> >>> index d0e445e..3c3bf98 100644
> >>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >>> @@ -359,6 +359,33 @@ static int per_file_stats(int id, void *ptr,
> >>> void
> >> *data)
> >>>   return 0;
> >>>   }
> >>>
> >>> +#define print_file_stats(m, name, stats) \
> >>> + seq_printf(m, "%s: %u objects, %zu bytes (%zu active, %zu
> >>> +inactive,
> >> %zu global, %zu shar

[Intel-gfx] [PATCH 2/4] drm/i915: Changes related to the sequence port no for

[Gaurav K Singh]

From now on for both DSI Ports A & C, the seq_port value has been
set to 0. seq_port value is parsed from Sequence block#53 of VBT.
So, for packets that needs to be read/write for DSI single link on
Port A and Port C will now be based on the DVO port from VBT block 2,
instead of seq_port.

Signed-off-by: Gaurav K Singh 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f8c2269..5493aef 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -110,7 +110,15 @@ static u8 *mipi_exec_send_packet(struct intel_dsi 
*intel_dsi, u8 *data)
vc = (byte >> MIPI_VIRTUAL_CHANNEL_SHIFT) & 0x3;
seq_port = (byte >> MIPI_PORT_SHIFT) & 0x3;
 
-   port = intel_dsi_seq_port_to_port(seq_port);
+   /* For DSI single link on Port A & C, the seq_port value which is
+* parsed from Sequence Block#53 of VBT has been set to 0
+* Now, read/write of packets for the DSI single link on Port A and
+* Port C will based on the DVO port from VBT block 2.
+*/
+   if (intel_dsi->ports == (1 << PORT_C))
+   port = PORT_C;
+   else
+   port = intel_dsi_seq_port_to_port(seq_port);
/* LP or HS mode */
intel_dsi->hs = mode;
 
-- 
1.7.9.5

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

[Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[Daniel Vetter]

Faster feedback to errors is always better. This is inspired by the
addition to WARN_ONs to mask/enable helpers for registers to make sure
callers have the arguments ordered correctly: Pretty much always the
arguments are static.

We use WARN_ON(1) a lot in default switch statements though where we
should always handle all cases. So add a new macro specifically for
that.

The idea to use __builtin_constant_p is from Chris Wilson.

v2: Use the ({}) gcc-ism to avoid the static inline, suggested by
Dave. My first attempt used __cond as the temp var, which is the same
used by BUILD_BUG_ON, but with inverted sense. Hilarity ensued, so
sprinkle i915 into the name.

Also use a temporary variable to only evaluate the condition once,
suggested by Damien.

v3: It's crazy but apparently 32bit gcc can't compile out the
BUILD_BUG_ON in a lot of cases and just falls over. I have no idea
why, but until clue grows just disable this nifty idea on 32bit
builds. Reported by 0-day builder.

v4: Got it all wrong, apparently its the gcc version. We need 4.9+.
Now reported by Imre.

v5: Chris suggested to add the case to MISSING_CASE for speedier
debug.

Cc: Imre Deak 
Cc: Damien Lespiau 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Dave Gordon 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  | 14 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c  |  6 +++---
 drivers/gpu/drm/i915/intel_display.c |  4 ++--
 drivers/gpu/drm/i915/intel_uncore.c  |  4 ++--
 5 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 165a38f36009..479e0c119111 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2347,7 +2347,7 @@ static const char *power_domain_str(enum 
intel_display_power_domain domain)
case POWER_DOMAIN_INIT:
return "INIT";
default:
-   WARN_ON(1);
+   MISSING_CASE(domain);
return "?";
}
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c74dc946cbf6..aeb1ef3ef2b6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -58,7 +58,19 @@
 #define DRIVER_DATE"20141205"
 
 #undef WARN_ON
-#define WARN_ON(x) WARN(x, "WARN_ON(" #x ")")
+/* Only 4.9+ gcc can compile away the BUILD_BUG_ON correctly. */
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 9)
+#define WARN_ON(x) ({ \
+   bool __i915_warn_cond = (x); \
+   if (__builtin_constant_p(__i915_warn_cond)) \
+   BUILD_BUG_ON(__i915_warn_cond); \
+   WARN(__i915_warn_cond, "WARN_ON(" #x ")"); })
+#else
+#define WARN_ON(x) WARN((x), "WARN_ON(" #x ")")
+#endif
+
+#define MISSING_CASE(x) WARN(1, "Missing switch case (%lu) in %s\n", \
+(long) (x), __func__);
 
 enum pipe {
INVALID_PIPE = -1,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index ac03a382000b..ce4e46c443a1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -132,7 +132,7 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE(level);
}
 
return pte;
@@ -156,7 +156,7 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
pte |= GEN6_PTE_UNCACHED;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE(level);
}
 
return pte;
@@ -1146,7 +1146,7 @@ int i915_ppgtt_init_hw(struct drm_device *dev)
else if (INTEL_INFO(dev)->gen >= 8)
gen8_ppgtt_enable(dev);
else
-   WARN_ON(1);
+   MISSING_CASE(INTEL_INFO(dev)->gen);
 
if (ppgtt) {
for_each_ring(ring, dev_priv, i) {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 841af6c1f50b..878c4857ff49 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4847,7 +4847,7 @@ static void cherryview_set_cdclk(struct drm_device *dev, 
int cdclk)
cmd = 0;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE(cdclk);
return;
}
 
@@ -8224,7 +8224,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 
base)
cntl |= CURSOR_MODE_256_ARGB_AX;
break;
default:
-   WARN_ON(1);
+   MISSING_CASE(intel_crtc->cursor_width);
return;
}
cntl |= pipe << 28; /* Connect to correct pipe */
diff --git a/drivers/gpu/drm/i915/intel

Re: [Intel-gfx] [PATCH] drm/i915: Call the lrc irq handler correctly

[Daniel, Thomas]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
> Sent: Wednesday, December 10, 2014 4:44 PM
> To: Intel Graphics Development
> Cc: Daniel Vetter; Daniel, Thomas; Vetter, Daniel
> Subject: [PATCH] drm/i915: Call the lrc irq handler correctly
> 
> We consistently use the _irq_handler postfix for functions called in hardirq
> context. Especially when it's a non-static function hardirq is a crazy enough
> calling context to warrant this level of ocd. So rename it.
> 
> Cc: Thomas Daniel 
> Signed-off-by: Daniel Vetter 
> ---
Possible to rename the patch "Name the lrc irq handler correctly" before 
merging?  Sounds like it was being called from the wrong place.

No problem with this renaming though so:
Reviewed-by: Thomas Daniel 

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

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

[Paolo Bonzini]

On 09/12/2014 03:49, Tian, Kevin wrote:
> - Now we have XenGT/KVMGT separately maintained, and KVMGT lags
> behind XenGT regarding to features and qualities. Likely you'll continue
> see stale code (like Xen inst decoder) for some time. In the future we
> plan to maintain a single kernel repo for both, so KVMGT can share
> same quality as XenGT once KVM in-kernel dm framework is stable.
> 
> - Regarding to Qemu hacks, KVMGT really doesn't have any different 
> requirements as what have been discussed for GPU pass-through, e.g. 
> about ISA bridge. Our implementation is based on an old Qemu repo, 
> and honestly speaking not cleanly developed, because we know we
> can leverage from GPU pass-through support once it's in Qemu. At 
> that time we'll leverage the same logic with minimal changes to 
> hook KVMGT mgmt. APIs (e.g. create/destroy a vGPU instance). So
> we can ignore this area for now. :-)

Could the virtual device model introduce new registers in order to avoid
poking at the ISA bridge?  I'm not sure that you "can leverage from GPU
pass-through support once it's in Qemu", since the Xen IGD passthrough
support is being added to a separate machine that is specific to Xen IGD
passthrough; no ISA bridge hacking will probably be allowed on the "-M
pc" and "-M q35" machine types.

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Changes related to the sequence port no for

[Daniel Vetter]

On Wed, Dec 10, 2014 at 10:07:40PM +0530, Gaurav K Singh wrote:
> From now on for both DSI Ports A & C, the seq_port value has been
> set to 0. seq_port value is parsed from Sequence block#53 of VBT.
> So, for packets that needs to be read/write for DSI single link on
> Port A and Port C will now be based on the DVO port from VBT block 2,
> instead of seq_port.
> 
> Signed-off-by: Gaurav K Singh 
> Reviewed-by: Jani Nikula 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 1/5] drm/i915: Implement a framework for batch buffer pools

[Michael H. Nguyen]

On 12/10/2014 08:41 AM, Bloomfield, Jon wrote:

why do we take the batch_pool lock in i915_gem_batch_pool_info() ?
i915_gem_batch_pool_info() is a new debugfs entry while 
print_batch_pool_stats() is just an internal fnc, called from the 
debugfs entry i915_gem_object_info(). i915_gem_object_info() handles the 
locks.

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Forcewake Register Range changes for CHV

[Daniel Vetter]

On Thu, Dec 11, 2014 at 09:42:49PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S 
> 
> According to updated BSpec, Render/Common/media Wells register range changed.
> Updating the same to match the spec and avoid extra forcewake for none
> forcewake range.
> 
> v2: Update media forcewake range (Ville)
> 
> Signed-off-by: Deepak S 
> Reviewed-by: Ville Syrjälä 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Prelude to splitting i915_gem_do_execbuffer in two

[Daniel Vetter]

On Wed, Dec 10, 2014 at 04:33:14PM +, Dave Gordon wrote:
> On 10/12/14 10:58, Daniel Vetter wrote:
> > On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
> >> From: John Harrison 
> >>
> >> The scheduler decouples the submission of batch buffers to the driver with 
> >> their
> >> submission to the hardware. This basically means splitting the execbuffer()
> >> function in half. This change rearranges some code ready for the split to 
> >> occur.
> > 
> > Now there's the curios question: Where will the split in top/bottom halves
> > be? Without that I have no idea whether it makes sense and so can't review
> > this patch. At least if the goal is to really prep for the scheduler and
> > not just move a few lines around ;-)
> > -Daniel
> > 
> [snip]
> >>  
> >> +  i915_gem_execbuffer_move_to_active(vmas, ring);
> >> +
> >> +  /* To be split into two functions here... */
> >> +
> >> +  /* Unconditionally invalidate gpu caches and ensure that we do flush
> >> +   * any residual writes from the previous batch.
> >> +   */
> >> +  ret = logical_ring_invalidate_all_caches(ringbuf);
> 
> It'll be where the marker comment is above. Ahead of that point is stuff
> to do with setting up software state; after that we're talking to h/w.
> When the scheduler code goes it, it decouples the two by interposing at
> this point. Then batches go into it with s/w state set up, but don't get
> to talk to the h/w until they're selected for execution, possibly in a
> different order.

Oops, I guess I need see a doctor to check my eyesight ;-)

Two comments about code that's still in the bottom half:
- There's lots of input validation code still below that cutoff point
  which needs to be moved above to still be able to return -EINVAL. Test
  coverage is the critical part here, but I think we've closed most of our
  gaps. I guess a future patch will address this?

- retire_commands and so add_request are also in the cutoff. For shrinker
  interactions to work seamlessly we need to have both the objects on the
  active list and the request in the lists. So I expect more untangling
  there to separate the request emission to rings from the bookkeeping
  parts in add_request.

Also move_to_active will fall apart once we start to reorder requests I
think. Need to think about this case more, but we definitely need some
testcases with depencies and reordering by the scheduler.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Disable 'get seqno' workaround for VLV

[Dave Gordon]

On 10/12/14 10:42, Daniel Vetter wrote:
> On Tue, Dec 09, 2014 at 12:59:08PM +, john.c.harri...@intel.com wrote:
>> From: Dave Gordon 
>>
>> There is a workaround for a hardware bug when reading the seqno from the 
>> status
>> page. The bug does not exist on VLV however, the workaround was still being
>> applied.
> 
> Given how much trouble the missed seqno fun cause us I'd like more
> justification. What kind of (stress)-testing has been done here? And
> you're sure you've never seen the little dmesg notice that the kernel
> switched to polling?
> -Daniel

This was necessary during VLV scheduler/preemption work, where we
stressed the command streamer and IRQ path probably more than any of the
usual tests, since we were looking for out-of-sequence anomalies.

The comments in gen6_ring_get_seqno() say it's to fix a bug on ivb/snb,
and nothing in the BSpec suggests it's needed on later chips.

I think the problem was really in the fact that the workaround
implemented in gen6_ring_get_seqno() was reading a nonshadowed register,
therefore triggering forcewake activity, which was pretty buggy; so we
took out the gen6-specific code before finding that there were still
other problems with forcewake.

[Aside]
The original intention appears to have been to generate a single I/O
READ cycle, forcing all pending inbound DMA so be flushed to memory, so
that the subsequent memory read would see the latest value. But now, it
doesn't just generate a single cycle but a whole flurry of writes and
polling reads, because reading ACTHD requires forcewake (unless that was
wrong, and has now been fixed). So should gen6_ring_get_seqno() instead
read a register that doesn't require forcewake? I wouldn't object to
using it in perpetuity if it really only read one register!
[/aside]

.Dave.

>> Change-Id: Ic781fdb31e1f794ce1fa8a6d0d5ee379756c5db6
>> Signed-off-by: Dave Gordon 
>> ---
>>  drivers/gpu/drm/i915/intel_ringbuffer.c |5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index 3887f1a..f990ce4 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> @@ -2367,7 +2367,10 @@ int intel_init_render_ring_buffer(struct drm_device 
>> *dev)
>>  ring->irq_get = gen6_ring_get_irq;
>>  ring->irq_put = gen6_ring_put_irq;
>>  ring->irq_enable_mask = GT_RENDER_USER_INTERRUPT;
>> -ring->get_seqno = gen6_ring_get_seqno;
>> +if (IS_VALLEYVIEW(dev))
>> +ring->get_seqno = ring_get_seqno;
>> +else
>> +ring->get_seqno = gen6_ring_get_seqno;
>>  ring->set_seqno = ring_set_seqno;
>>  if (i915_semaphore_is_enabled(dev)) {
>>  ring->semaphore.sync_to = gen6_ring_sync;
>> -- 
>> 1.7.9.5
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 

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

[Intel-gfx] [PATCH i-g-t v2 1/2] lib: introduce log domains

[Thomas Wood]

Log domains can be used to identify the source of log messages, such as
the test being run or the helper library.

v2: Add separate domains for different parts of the helper library and
use an empty default domain for applications.
Expand the log output to include the process name and the log level
of the message in addition to the domain and pid.
Print the expanded message only for warning and information
messages.

Signed-off-by: Thomas Wood 
---
 lib/Makefile.am |  3 ++-
 lib/igt_core.c  | 28 ++--
 lib/igt_core.h  | 18 +++---
 lib/igt_kms.c   |  2 +-
 4 files changed, 36 insertions(+), 15 deletions(-)

diff --git a/lib/Makefile.am b/lib/Makefile.am
index ab82302..3826a1c 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -10,7 +10,8 @@ noinst_HEADERS = check-ndebug.h
 
 AM_CPPFLAGS = -I$(top_srcdir)
 AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS)  \
-   -DIGT_DATADIR=\""$(abs_top_srcdir)/tests"\"
+   -DIGT_DATADIR=\""$(abs_top_srcdir)/tests"\" \
+   -DIGT_LOG_DOMAIN=\""$(subst _,-,$*)"\"
 
 
 LDADD = $(CAIRO_LIBS)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 13a52a5..b6852dd 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1429,12 +1429,12 @@ void igt_skip_on_simulation(void)
  * are disabled. "none" completely disables all output and is not recommended
  * since crucial issues only reported at the IGT_LOG_WARN level are ignored.
  */
-void igt_log(enum igt_log_level level, const char *format, ...)
+void igt_log(const char *domain, enum igt_log_level level, const char *format, 
...)
 {
va_list args;
 
va_start(args, format);
-   igt_vlog(level, format, args);
+   igt_vlog(domain, level, format, args);
va_end(args);
 }
 
@@ -1451,8 +1451,16 @@ void igt_log(enum igt_log_level level, const char 
*format, ...)
  * If there is no need to wrap up a vararg list in the caller it is simpler to
  * just use igt_log().
  */
-void igt_vlog(enum igt_log_level level, const char *format, va_list args)
+void igt_vlog(const char *domain, enum igt_log_level level, const char 
*format, va_list args)
 {
+   FILE *file;
+   const char *igt_log_level_str[] = {
+   "DEBUG",
+   "INFO",
+   "WARNING",
+   "NONE"
+   };
+
assert(format);
 
if (list_subtests)
@@ -1462,10 +1470,18 @@ void igt_vlog(enum igt_log_level level, const char 
*format, va_list args)
return;
 
if (level == IGT_LOG_WARN) {
+   file = stderr;
fflush(stdout);
-   vfprintf(stderr, format, args);
-   } else
-   vprintf(format, args);
+   }
+   else
+   file = stdout;
+
+   if (level != IGT_LOG_INFO) {
+   fprintf(file, "(%s:%d) %s%s%s: ", program_invocation_short_name,
+   getpid(), (domain) ? domain : "", (domain) ? "-" : "",
+   igt_log_level_str[level]);
+   }
+   vfprintf(file, format, args);
 }
 
 static void igt_alarm_handler(int signal)
diff --git a/lib/igt_core.h b/lib/igt_core.h
index a258348..5c5ee25 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -512,16 +512,20 @@ bool igt_run_in_simulation(void);
 void igt_skip_on_simulation(void);
 
 /* structured logging */
+#ifndef IGT_LOG_DOMAIN
+#define IGT_LOG_DOMAIN (NULL)
+#endif
+
 enum igt_log_level {
IGT_LOG_DEBUG,
IGT_LOG_INFO,
IGT_LOG_WARN,
IGT_LOG_NONE,
 };
-__attribute__((format(printf, 2, 3)))
-void igt_log(enum igt_log_level level, const char *format, ...);
-__attribute__((format(printf, 2, 0)))
-void igt_vlog(enum igt_log_level level, const char *format, va_list args);
+__attribute__((format(printf, 3, 4)))
+void igt_log(const char *domain, enum igt_log_level level, const char *format, 
...);
+__attribute__((format(printf, 3, 0)))
+void igt_vlog(const char *domain, enum igt_log_level level, const char 
*format, va_list args);
 
 /**
  * igt_debug:
@@ -529,7 +533,7 @@ void igt_vlog(enum igt_log_level level, const char *format, 
va_list args);
  *
  * Wrapper for igt_log() for message at the IGT_LOG_DEBUG level.
  */
-#define igt_debug(f...) igt_log(IGT_LOG_DEBUG, f)
+#define igt_debug(f...) igt_log(IGT_LOG_DOMAIN, IGT_LOG_DEBUG, f)
 
 /**
  * igt_info:
@@ -537,7 +541,7 @@ void igt_vlog(enum igt_log_level level, const char *format, 
va_list args);
  *
  * Wrapper for igt_log() for message at the IGT_LOG_INFO level.
  */
-#define igt_info(f...) igt_log(IGT_LOG_INFO, f)
+#define igt_info(f...) igt_log(IGT_LOG_DOMAIN, IGT_LOG_INFO, f)
 
 /**
  * igt_warn:
@@ -545,7 +549,7 @@ void igt_vlog(enum igt_log_level level, const char *format, 
va_list args);
  *
  * Wrapper for igt_log() for message at the IGT_LOG_WARN level.
  */
-#define igt_warn(f...) igt_log(IGT_LOG_WARN, f)
+#define igt_warn(f...) igt_log(IGT_LOG_DOMAIN, IGT_LOG_WARN, f)
 extern enum igt_log_level igt_log_level;
 
 /**
diff --git a/lib/igt_kms.c b/lib/i

[Intel-gfx] [PATCH i-g-t v2 2/2] lib: add optional log domain filtering

[Thomas Wood]

v2: add an "application" filter for the default domain (used by
applications)

Signed-off-by: Thomas Wood 
---
 docs/reference/intel-gpu-tools/igt_test_programs.xml |  6 --
 lib/igt_core.c   | 17 +++--
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/docs/reference/intel-gpu-tools/igt_test_programs.xml 
b/docs/reference/intel-gpu-tools/igt_test_programs.xml
index 970ecb9..36ad1f3 100644
--- a/docs/reference/intel-gpu-tools/igt_test_programs.xml
+++ b/docs/reference/intel-gpu-tools/igt_test_programs.xml
@@ -35,9 +35,11 @@
   
 
   
---debug
+--debug[=log-domain]
 
-print extra debugging information when running tests
+print extra debugging information when running tests and
+optionaly only show the messages from the specified log domain
+(use "application" to specifiy the default application domain)
 
   
 
diff --git a/lib/igt_core.c b/lib/igt_core.c
index b6852dd..695437c 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -228,6 +228,8 @@ enum {
  OPT_HELP = 'h'
 };
 
+static char* igt_log_domain_filter;
+
 __attribute__((format(printf, 1, 2)))
 static void kmsg(const char *format, ...)
 #define KERN_EMER  "<0>"
@@ -390,7 +392,7 @@ static void print_usage(const char *help_str, bool 
output_on_stderr)
fprintf(f, "Usage: %s [OPTIONS]\n", command_str);
fprintf(f, "  --list-subtests\n"
   "  --run-subtest \n"
-  "  --debug\n"
+  "  --debug[=log-domain]\n"
   "  --help-description\n"
   "  --help\n");
if (help_str)
@@ -422,7 +424,7 @@ static int common_init(int argc, char **argv,
{"list-subtests", 0, 0, OPT_LIST_SUBTESTS},
{"run-subtest", 1, 0, OPT_RUN_SUBTEST},
{"help-description", 0, 0, OPT_DESCRIPTION},
-   {"debug", 0, 0, OPT_DEBUG},
+   {"debug", optional_argument, 0, OPT_DEBUG},
{"help", 0, 0, OPT_HELP},
{0, 0, 0, 0}
};
@@ -510,6 +512,8 @@ static int common_init(int argc, char **argv,
switch(c) {
case OPT_DEBUG:
igt_log_level = IGT_LOG_DEBUG;
+   if (optarg && strlen(optarg) > 0)
+   igt_log_domain_filter = strdup(optarg);
break;
case OPT_LIST_SUBTESTS:
if (!run_single_subtest)
@@ -1469,6 +1473,15 @@ void igt_vlog(const char *domain, enum igt_log_level 
level, const char *format,
if (igt_log_level > level)
return;
 
+   if (igt_log_domain_filter) {
+   /* if null domain and filter is not "application", return */
+   if (!domain && strcmp(igt_log_domain_filter, "application"))
+   return;
+   /* else if domain and filter do not match, return */
+   else if (domain && strcmp(igt_log_domain_filter, domain))
+   return;
+   }
+
if (level == IGT_LOG_WARN) {
file = stderr;
fflush(stdout);
-- 
2.1.0

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

[Intel-gfx] [PATCH 1/2] drm/i915: Infrastructure for supporting different GGTT views per object

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
to map objects into the same address space multiple times.

Added a GGTT view concept and linked it with the VMA to distinguish between
multiple instances per address space.

New objects and GEM functions which do not take this new view as a parameter
assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the
previous behaviour.

This now means that objects can have multiple VMA entries so the code which
assumed there will only be one also had to be modified.

Alternative GGTT views are supposed to borrow DMA addresses from obj->pages
which is DMA mapped on first VMA instantiation and unmapped on the last one
going away.

v2:
* Removed per view special casing in i915_gem_ggtt_prepare /
  finish_object in favour of creating and destroying DMA mappings
  on first VMA instantiation and last VMA destruction. (Daniel Vetter)
* Simplified i915_vma_unbind which does not need to count the GGTT views.
  (Daniel Vetter)
* Also moved obj->map_and_fenceable reset under the same check.
* Checkpatch cleanups.

v3:
* Only retire objects once the last VMA is unbound.

v4:
* Keep scatter-gather table for alternative views persistent for the
  lifetime of the VMA.
* Propagate binding errors to callers and handle appropriately.

v5:
* Explicitly look for normal GGTT view in i915_gem_obj_bound to align
  usage in i915_gem_object_ggtt_unpin. (Michel Thierry)
* Change to single if statement in i915_gem_obj_to_ggtt. (Michel Thierry)
* Removed stray semi-colon in i915_gem_object_set_cache_level.

For: VIZ-4544
Signed-off-by: Tvrtko Ursulin 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c|   5 +-
 drivers/gpu/drm/i915/i915_drv.h|  56 +--
 drivers/gpu/drm/i915/i915_gem.c| 112 +
 drivers/gpu/drm/i915/i915_gem_context.c|  11 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   9 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.c|  70 +++---
 drivers/gpu/drm/i915/i915_gem_gtt.h|  22 ++
 drivers/gpu/drm/i915/i915_gpu_error.c  |   8 +--
 8 files changed, 221 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e445e..a8af667 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -152,8 +152,9 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
seq_puts(m, " (pp");
else
seq_puts(m, " (g");
-   seq_printf(m, "gtt offset: %08lx, size: %08lx)",
-  vma->node.start, vma->node.size);
+   seq_printf(m, "gtt offset: %08lx, size: %08lx, type: %u)",
+  vma->node.start, vma->node.size,
+  vma->ggtt_view.type);
}
if (obj->stolen)
seq_printf(m, " (stolen: %08lx)", obj->stolen->start);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11e85cb..451bb6a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2518,10 +2518,23 @@ void i915_gem_vma_destroy(struct i915_vma *vma);
 #define PIN_GLOBAL 0x4
 #define PIN_OFFSET_BIAS 0x8
 #define PIN_OFFSET_MASK (~4095)
+int __must_check i915_gem_object_pin_view(struct drm_i915_gem_object *obj,
+ struct i915_address_space *vm,
+ uint32_t alignment,
+ uint64_t flags,
+ const struct i915_ggtt_view *view);
+static inline
 int __must_check i915_gem_object_pin(struct drm_i915_gem_object *obj,
 struct i915_address_space *vm,
 uint32_t alignment,
-uint64_t flags);
+uint64_t flags)
+{
+   return i915_gem_object_pin_view(obj, vm, alignment, flags,
+   &i915_ggtt_view_normal);
+}
+
+int i915_vma_bind(struct i915_vma *vma, enum i915_cache_level cache_level,
+ u32 flags);
 int __must_check i915_vma_unbind(struct i915_vma *vma);
 int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
 void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
@@ -2683,18 +2696,51 @@ struct dma_buf *i915_gem_prime_export(struct drm_device 
*dev,
 
 void i915_gem_restore_fences(struct drm_device *dev);
 
+unsigned long i915_gem_obj_offset_view(struct drm_i915_gem_object *o,
+  struct i915_address_space *vm,
+  enum i915_ggtt_view_type view);
+static inline
 unsigned long i915_gem_obj_offset(struct drm_i915_gem_object *o,
- 

[Intel-gfx] [PATCH v3 0/2] Multiple GGTT views

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

This series continues what was previously a single patch called "drm/i915:
Infrastructure for supporting different GGTT views per object".

v2:
 * One less patch due early prep work getting merged.
 * Main patch reworked to keep the pages pointer around for the lifetime of the
   VMA. More detailed changelog in the patch itself.

v3:
 * Addressing review comments - see individual changelogs.

Tvrtko Ursulin (2):
  drm/i915: Infrastructure for supporting different GGTT views per
object
  drm/i915: Documentation for multiple GGTT views

 Documentation/DocBook/drm.tmpl |   5 ++
 drivers/gpu/drm/i915/i915_debugfs.c|   5 +-
 drivers/gpu/drm/i915/i915_drv.h|  56 +++--
 drivers/gpu/drm/i915/i915_gem.c| 112 +++--
 drivers/gpu/drm/i915/i915_gem_context.c|  11 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   9 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c| 130 +++--
 drivers/gpu/drm/i915/i915_gem_gtt.h|  22 +
 drivers/gpu/drm/i915/i915_gpu_error.c  |   8 +-
 9 files changed, 286 insertions(+), 72 deletions(-)

-- 
2.1.1

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

[Intel-gfx] [PATCH 2/2] drm/i915: Documentation for multiple GGTT views

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

A short section describing background, implementation and intended usage.

v2:
* Align section name between template and DOC comment. (Michel Thierry)

For: VIZ-4544
Signed-off-by: Tvrtko Ursulin 
---
 Documentation/DocBook/drm.tmpl  |  5 
 drivers/gpu/drm/i915/i915_gem_gtt.c | 60 +
 2 files changed, 65 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 85287cb..eb84da73 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4033,6 +4033,11 @@ int num_ioctls;
 !Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and 
Execlists
 !Idrivers/gpu/drm/i915/intel_lrc.c
   
+  
+Global GTT views
+!Pdrivers/gpu/drm/i915/i915_gem_gtt.c Global GTT views
+!Idrivers/gpu/drm/i915/i915_gem_gtt.c
+  
 
 
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 73c1c0b..534ebc1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -30,6 +30,66 @@
 #include "i915_trace.h"
 #include "intel_drv.h"
 
+/**
+ * DOC: Global GTT views
+ *
+ * Background and previous state
+ *
+ * Historically objects could exists (be bound) in global GTT space only as
+ * singular instances with a view representing all of the object's backing 
pages
+ * in a linear fashion. This view will be called a normal view.
+ *
+ * To support multiple views of the same object, where the number of mapped
+ * pages is not equal to the backing store, or where the layout of the pages
+ * is not linear, concept of a GGTT view was added.
+ *
+ * One example of an alternative view is a stereo display driven by a single
+ * image. In this case we would have a framebuffer looking like this
+ * (2x2 pages):
+ *
+ *12
+ *34
+ *
+ * Above would represent a normal GGTT view as normally mapped for GPU or CPU
+ * rendering. In contrast, fed to the display engine would be an alternative
+ * view which could look something like this:
+ *
+ *   1212
+ *   3434
+ *
+ * In this example both the size and layout of pages in the alternative view is
+ * different from the normal view.
+ *
+ * Implementation and usage
+ *
+ * GGTT views are implemented using VMAs and are distinguished via enum
+ * i915_ggtt_view_type and struct i915_ggtt_view.
+ *
+ * A new flavour of core GEM functions which work with GGTT bound objects were
+ * added with the _view suffix. They take the struct i915_ggtt_view parameter
+ * encapsulating all metadata required to implement a view.
+ *
+ * As a helper for callers which are only interested in the normal view,
+ * globally const i915_ggtt_view_normal singleton instance exists. All old core
+ * GEM API functions, the ones not taking the view parameter, are operating on,
+ * or with the normal GGTT view.
+ *
+ * Code wanting to add or use a new GGTT view needs to:
+ *
+ * 1. Add a new enum with a suitable name.
+ * 2. Extend the metadata in the i915_ggtt_view structure if required.
+ * 3. Add support to i915_get_vma_pages().
+ *
+ * New views are required to build a scatter-gather table from within the
+ * i915_get_vma_pages function. This table is stored in the vma.ggtt_view and
+ * exists for the lifetime of an VMA.
+ *
+ * Core API is designed to have copy semantics which means that passed in
+ * struct i915_ggtt_view does not need to be persistent (left around after
+ * calling the core API functions).
+ *
+ */
+
 const struct i915_ggtt_view i915_ggtt_view_normal;
 
 static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv);
-- 
2.1.1

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

Re: [Intel-gfx] [PATCH] drm/i915: vlv: fix IRQ masking when uninstalling interrupts

[Ville Syrjälä]

On Thu, Nov 20, 2014 at 04:05:55PM +0200, Imre Deak wrote:
> irq_mask should include all IRQ bits that we want to mask, but atm we
> set it incorrectly to the inverse of this. If the mask is used
> subsequently to enable/disable some IRQ bits, we may unintentionally
> unmask unrelated IRQs. I can't see any way that this can lead to a real
> problem in the current -nightly code, since the first place the mask
> will be used next (after a suspend/resume cycle) is in
> valleyview_irq_postinstall(), but the mask is reset there to its proper
> value.
> 
> This causes a problem in the upstream kernel though, where - due to another
> issue - the mask is used in the above way to disable only the display IRQs.
> This other issue is fixed by:
> 
> commit 950eabaf5a87257040e0c207be09487954113f54
> Author: Imre Deak 
> Date:   Mon Sep 8 15:21:09 2014 +0300
> 
> drm/i915: vlv: fix display IRQ enable/disable
> 
> Interestingly, even with the above two bugs, we shouldn't in theory have
> any real problems (arguably a famous last sentence:). That's because
> even if we unmask something unintentionally via the VLV_IMR/VLV_IER
> register the master IRQ masking bit in VLV_MASTER_IER is still set and
> should prevent all i915 interrupts. According to my testing on an ASUS
> T100 with DSI output this isn't the case at least with the
> MIPIA_INTERRUPT. Leaving this one unmasked in IMR/IER, while having
> VLV_MASTER_IER set to 0 may lead to a lockup during system suspend as
> shown in the bugzilla ticket below. This fix should get rid of the
> problem reported there in upstream and older kernels.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85920
> Cc: sta...@vger.kernel.org (v3.15+)
> Signed-off-by: Imre Deak 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 8d169e1..4601f53 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3597,7 +3597,7 @@ static void vlv_display_irq_uninstall(struct 
> drm_i915_private *dev_priv)
>  
>   vlv_display_irq_reset(dev_priv);
>  
> - dev_priv->irq_mask = 0;
> + dev_priv->irq_mask = ~0;
>  }
>  
>  static void valleyview_irq_uninstall(struct drm_device *dev)
> -- 
> 1.8.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH v2] drm/i915: FIFO space query code refactor

[Dave Gordon]

When querying the GTFIFOCTL register to check the FIFO space, the read value
must be masked. The operation is repeated explicitly in several places. This
change refactors the read-and-mask code into a function call.

v2: rebased on top of Mika's forcewake patch set, specifically:
[PATCH 8/8] drm/i915: Enum forcewake domains and domain identifiers

Change-Id: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef
Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/intel_uncore.c |   19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 66365e7..a0331a7 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -205,6 +205,13 @@ static void fw_domains_put_with_fifo(struct 
drm_i915_private *dev_priv,
gen6_gt_check_fifodbg(dev_priv);
 }
 
+static inline u32 fifo_free_entries(struct drm_i915_private *dev_priv)
+{
+   u32 count = __raw_i915_read32(dev_priv, GTFIFOCTL);
+
+   return count & GT_FIFO_FREE_ENTRIES_MASK;
+}
+
 static int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
 {
int ret = 0;
@@ -212,16 +219,15 @@ static int __gen6_gt_wait_for_fifo(struct 
drm_i915_private *dev_priv)
/* On VLV, FIFO will be shared by both SW and HW.
 * So, we need to read the FREE_ENTRIES everytime */
if (IS_VALLEYVIEW(dev_priv->dev))
-   dev_priv->uncore.fifo_count =
-   __raw_i915_read32(dev_priv, GTFIFOCTL) &
-   GT_FIFO_FREE_ENTRIES_MASK;
+   dev_priv->uncore.fifo_count = fifo_free_entries(dev_priv);
 
if (dev_priv->uncore.fifo_count < GT_FIFO_NUM_RESERVED_ENTRIES) {
int loop = 500;
-   u32 fifo = __raw_i915_read32(dev_priv, GTFIFOCTL) & 
GT_FIFO_FREE_ENTRIES_MASK;
+   u32 fifo = fifo_free_entries(dev_priv);
+
while (fifo <= GT_FIFO_NUM_RESERVED_ENTRIES && loop--) {
udelay(10);
-   fifo = __raw_i915_read32(dev_priv, GTFIFOCTL) & 
GT_FIFO_FREE_ENTRIES_MASK;
+   fifo = fifo_free_entries(dev_priv);
}
if (WARN_ON(loop < 0 && fifo <= GT_FIFO_NUM_RESERVED_ENTRIES))
++ret;
@@ -277,8 +283,7 @@ void intel_uncore_forcewake_reset(struct drm_device *dev, 
bool restore)
 
if (IS_GEN6(dev) || IS_GEN7(dev))
dev_priv->uncore.fifo_count =
-   __raw_i915_read32(dev_priv, GTFIFOCTL) &
-   GT_FIFO_FREE_ENTRIES_MASK;
+   fifo_free_entries(dev_priv);
}
 
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH] drm/i915: Use BUILD_BUG if possible in the i915 WARN_ON

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  364/364  364/364
ILK  +1 364/366  365/366
SNB  448/450  448/450
IVB  497/498  497/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(3, M26)PASS(16, M26M37)   
   PASS(1, M37)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2] lib: add a function to lock memory into RAM

[Thomas Wood]

Add a function to lock memory into RAM and use it in the
gem_tiled_swapping test to reduce the amount of allocated memory
required to force swapping. This also reduces the amount of time
required for the test to complete, since the data set is smaller.

The following durations were recorded on a haswell system before this
change:

  Subtest non-threaded: SUCCESS (55.889s)
  Subtest threaded: SUCCESS (810.532s)

and after:

  Subtest non-threaded: SUCCESS (11.804s)
  Subtest threaded: SUCCESS (268.336s)

v2: add various assertions and requirements and make sure
gem_tiled_swapping works on systems with less RAM (Daniel Vetter)

Signed-off-by: Thomas Wood 
---
 lib/igt_aux.c  | 57 ++
 lib/igt_aux.h  |  3 +++
 tests/gem_tiled_swapping.c | 10 +++-
 3 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 3051d84..d8d8577 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -601,3 +601,60 @@ struct type_name connector_type_names[] = {
 };
 
 type_name_fn(connector_type)
+
+
+/**
+ * igt_lock_mem: @size: the amount of memory to lock into RAM, in MB
+ *
+ * Allocate @size MB of memory and lock it into RAM. This releases any
+ * previously locked memory.
+ *
+ * Use #igt_unlock_mem to release the currently locked memory.
+ */
+static char *locked_mem;
+static size_t locked_size;
+
+void igt_lock_mem(size_t size)
+{
+   long pagesize = sysconf(_SC_PAGESIZE);
+   size_t i;
+   int ret;
+
+   if (size == 0) {
+   return;
+   }
+
+   if (locked_mem) {
+   igt_unlock_mem();
+   igt_warn("Unlocking previously locked memory.\n");
+   }
+
+   locked_size = size * 1024 * 1024;
+
+   locked_mem = malloc(locked_size);
+   igt_require_f(locked_mem,
+ "Could not allocate enough memory to lock.\n");
+
+   /* write into each page to ensure it is allocated */
+   for (i = 0; i < locked_size; i += pagesize)
+   locked_mem[i] = i;
+
+   ret = mlock(locked_mem, locked_size);
+   igt_assert_f(ret == 0, "Could not lock memory into RAM.\n");
+}
+
+/**
+ * igt_unlock_mem:
+ *
+ * Release and free the RAM used by #igt_lock_mem.
+ */
+void igt_unlock_mem(void)
+{
+   if (!locked_mem)
+   return;
+
+   munlock(locked_mem, locked_size);
+
+   free(locked_mem);
+   locked_mem = NULL;
+}
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 63e1b06..c420b3f 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -96,4 +96,7 @@ void intel_require_memory(uint32_t count, uint32_t size, 
unsigned mode);
(b) = _tmp; \
 } while (0)
 
+void igt_lock_mem(size_t size);
+void igt_unlock_mem(void);
+
 #endif /* IGT_AUX_H */
diff --git a/tests/gem_tiled_swapping.c b/tests/gem_tiled_swapping.c
index 3fac52f..1637ec7 100644
--- a/tests/gem_tiled_swapping.c
+++ b/tests/gem_tiled_swapping.c
@@ -70,6 +70,7 @@ IGT_TEST_DESCRIPTION("Exercise swizzle code for swapping.");
 static uint32_t current_tiling_mode;
 
 #define PAGE_SIZE 4096
+#define AVAIL_RAM 512
 
 static uint32_t
 create_bo_and_fill(int fd)
@@ -151,13 +152,20 @@ igt_main
int fd, n, count, num_threads;
 
igt_fixture {
+   size_t lock_size;
+
current_tiling_mode = I915_TILING_X;
 
intel_purge_vm_caches();
 
fd = drm_open_any();
+
+   /* lock RAM, leaving only 512MB available */
+   lock_size = min(0, intel_get_total_ram_mb() - AVAIL_RAM);
+   igt_lock_mem(lock_size);
+
/* need slightly more than available memory */
-   count = intel_get_total_ram_mb() + intel_get_total_swap_mb() / 
4;
+   count = lock_size * 1.25;
bo_handles = calloc(count, sizeof(uint32_t));
igt_assert(bo_handles);
 
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Changes required to enable DSI Video Mode on CHT

[shuang . he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV -1  364/364  363/364
ILK  +1-3  364/366  362/366
SNB  448/450  448/450
IVB -1  497/498  496/498
BYT  289/289  289/289
HSW  563/564  563/564
BDW  417/417  417/417
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*PNV  igt_gem_fd_exhaustion  PASS(2, M23)  FAIL(1, M23)
*ILK  igt_kms_flip_flip-vs-dpms-interruptible  PASS(5, M26)  
DMESG_WARN(1, M26)
 ILK  igt_kms_flip_flip-vs-panning  DMESG_WARN(1, M26)PASS(7, M26)  
DMESG_WARN(1, M26)
*ILK  igt_kms_flip_flip-vs-rmfb-interruptible  NSPT(1, M26)PASS(4, M26) 
 DMESG_WARN(1, M26)
 ILK  igt_kms_flip_wf_vblank-ts-check  DMESG_WARN(3, M26)PASS(17, M26M37)   
   PASS(1, M26)
*IVB  igt_kms_cursor_crc_cursor-256x256-sliding  PASS(3, M4M21)  
DMESG_WARN(1, M21)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: save/restore GMBUS freq across suspend/resume on gen4

[Jesse Barnes]

Should probably just init this in the GMbus code all the time, based on
the cdclk and HPLL like we do on newer platforms.  Ville has code for
that in a rework branch, but until then we can fix this bug fairly
easily.

References: https://bugs.freedesktop.org/show_bug.cgi?id=76301
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_drv.h | 1 +
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 drivers/gpu/drm/i915/i915_suspend.c | 8 
 3 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2725243..f33102b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -925,6 +925,7 @@ struct i915_suspend_saved_registers {
u32 savePIPEB_LINK_N1;
u32 saveMCHBAR_RENDER_STANDBY;
u32 savePCH_PORT_HOTPLUG;
+   u16 saveGCDGMBUS;
 };
 
 struct vlv_s0ix_state {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc03fac..f7c2856 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -76,6 +76,7 @@
 #define   I915_GC_RENDER_CLOCK_166_MHZ (0 << 0)
 #define   I915_GC_RENDER_CLOCK_200_MHZ (1 << 0)
 #define   I915_GC_RENDER_CLOCK_333_MHZ (4 << 0)
+#define GCDGMBUS 0xcc
 #define PCI_LBPC 0xf4 /* legacy/combination backlight modes, also called LBB */
 
 
diff --git a/drivers/gpu/drm/i915/i915_suspend.c 
b/drivers/gpu/drm/i915/i915_suspend.c
index dfe6617..2636882 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -303,6 +303,10 @@ int i915_save_state(struct drm_device *dev)
}
}
 
+   if (IS_GEN4(dev))
+   pci_read_config_word(dev->pdev, GCDGMBUS,
+&dev_priv->regfile.saveGCDGMBUS);
+
/* Cache mode state */
if (INTEL_INFO(dev)->gen < 7)
dev_priv->regfile.saveCACHE_MODE_0 = I915_READ(CACHE_MODE_0);
@@ -331,6 +335,10 @@ int i915_restore_state(struct drm_device *dev)
mutex_lock(&dev->struct_mutex);
 
i915_gem_restore_fences(dev);
+
+   if (IS_GEN4(dev))
+   pci_write_config_word(dev->pdev, GCDGMBUS,
+ dev_priv->regfile.saveGCDGMBUS);
i915_restore_display(dev);
 
if (!drm_core_check_feature(dev, DRIVER_MODESET)) {
-- 
1.9.1

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

[Intel-gfx] [PATCH 5/8] drm/i915/bdw: Add support for DRRS to switch RR

[Vandana Kannan]

For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next frame
that is output.

Signed-off-by: Vandana Kannan 
Signed-off-by: Pradeep Bhat 
---
 drivers/gpu/drm/i915/intel_display.c |  9 +++--
 drivers/gpu/drm/i915/intel_dp.c  | 15 ++-
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 3 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a4a565c..411d34e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -88,9 +88,6 @@ static int intel_framebuffer_init(struct drm_device *dev,
  struct drm_i915_gem_object *obj);
 static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc);
 static void intel_set_pipe_timings(struct intel_crtc *intel_crtc);
-static void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
-struct intel_link_m_n *m_n,
-struct intel_link_m_n *m2_n2);
 static void ironlake_set_pipeconf(struct drm_crtc *crtc);
 static void haswell_set_pipeconf(struct drm_crtc *crtc);
 static void intel_set_pipe_csc(struct drm_crtc *crtc);
@@ -5795,9 +5792,9 @@ static void intel_pch_transcoder_set_m_n(struct 
intel_crtc *crtc,
I915_WRITE(PCH_TRANS_LINK_N1(pipe), m_n->link_n);
 }
 
-static void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
-struct intel_link_m_n *m_n,
-struct intel_link_m_n *m2_n2)
+void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
+struct intel_link_m_n *m_n,
+struct intel_link_m_n *m2_n2)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bc17900..38d61f2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4802,7 +4802,20 @@ static void intel_dp_set_drrs_state(struct drm_device 
*dev, int refresh_rate)
return;
}
 
-   if (INTEL_INFO(dev)->gen > 6 && INTEL_INFO(dev)->gen < 8) {
+   if (INTEL_INFO(dev)->gen >= 8) {
+   switch(index) {
+   case DRRS_HIGH_RR:
+   intel_dp_set_m_n(intel_crtc);
+   break;
+   case DRRS_LOW_RR:
+   intel_cpu_transcoder_set_m_n(intel_crtc,
+   &intel_crtc->config.dp_m2_n2, NULL);
+   break;
+   case DRRS_MAX_RR:
+   default:
+   break;
+   }
+   } else if (INTEL_INFO(dev)->gen > 6) {
reg = PIPECONF(intel_crtc->config.cpu_transcoder);
val = I915_READ(reg);
if (index > DRRS_HIGH_RR) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 763c097..bdfdea8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -952,6 +952,9 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv);
 void intel_dp_get_m_n(struct intel_crtc *crtc,
  struct intel_crtc_config *pipe_config);
 void intel_dp_set_m_n(struct intel_crtc *crtc);
+void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
+struct intel_link_m_n *m_n,
+struct intel_link_m_n *m2_n2);
 int intel_dotclock_calculate(int link_freq, const struct intel_link_m_n *m_n);
 void
 ironlake_check_encoder_dotclock(const struct intel_crtc_config *pipe_config,
-- 
2.0.1

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

[Intel-gfx] [PATCH 6/8] drm/i915: Support for RR switching on VLV

[Vandana Kannan]

Definition of VLV RR switch bit and corresponding toggling in
set_drrs function.

Signed-off-by: Vandana Kannan 
Signed-off-by: Uma Shankar 
Reviewed-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_reg.h |  1 +
 drivers/gpu/drm/i915/intel_dp.c | 10 --
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 78d89a7..16b426d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3821,6 +3821,7 @@ enum punit_power_well {
 #define   PIPECONF_INTERLACE_MODE_MASK (7 << 21)
 #define   PIPECONF_EDP_RR_MODE_SWITCH  (1 << 20)
 #define   PIPECONF_CXSR_DOWNCLOCK  (1<<16)
+#define   PIPECONF_EDP_RR_MODE_SWITCH_VLV  (1 << 14)
 #define   PIPECONF_COLOR_RANGE_SELECT  (1 << 13)
 #define   PIPECONF_BPC_MASK(0x7 << 5)
 #define   PIPECONF_8BPC(0<<5)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 38d61f2..ef8fa94 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4819,10 +4819,16 @@ static void intel_dp_set_drrs_state(struct drm_device 
*dev, int refresh_rate)
reg = PIPECONF(intel_crtc->config.cpu_transcoder);
val = I915_READ(reg);
if (index > DRRS_HIGH_RR) {
-   val |= PIPECONF_EDP_RR_MODE_SWITCH;
+   if (IS_VALLEYVIEW(dev))
+   val |= PIPECONF_EDP_RR_MODE_SWITCH_VLV;
+   else
+   val |= PIPECONF_EDP_RR_MODE_SWITCH;
intel_dp_set_m_n(intel_crtc);
} else {
-   val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
+   if (IS_VALLEYVIEW(dev))
+   val &= ~PIPECONF_EDP_RR_MODE_SWITCH_VLV;
+   else
+   val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
}
I915_WRITE(reg, val);
}
-- 
2.0.1

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

[Intel-gfx] [PATCH 4/8] drm/i915: DRRS calls based on frontbuffer

[Vandana Kannan]

Calls have been added to invalidate/flush DRRS whenever invalidate/flush is
called as part of frontbuffer tracking.
Apart from calls as a result of GEM tracking to fb invalidate/flush, a
call has been added to invalidate fb obj from crtc_page_flip as well. This
is to track busyness through flip calls.
The call to fb_obj_invalidate (in flip) is placed before queuing flip for this
obj.

drrs_invalidate() and drrs_flush() check for drrs.dp which would be NULL if
it was setup in drrs_enable(). This covers for the condition when DRRS is
not supported.

Signed-off-by: Vandana Kannan 
---
 drivers/gpu/drm/i915/intel_display.c |  8 +++--
 drivers/gpu/drm/i915/intel_dp.c  | 51 
 drivers/gpu/drm/i915/intel_drv.h |  3 ++
 drivers/gpu/drm/i915/intel_frontbuffer.c |  2 ++
 4 files changed, 61 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a9bdc12..a4a565c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9717,6 +9717,11 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (ret)
goto cleanup_pending;
 
+   i915_gem_track_fb(work->old_fb_obj, obj,
+ INTEL_FRONTBUFFER_PRIMARY(pipe));
+
+   intel_fb_obj_invalidate(obj, ring);
+
work->gtt_offset =
i915_gem_obj_ggtt_offset(obj) + intel_crtc->dspaddr_offset;
 
@@ -9741,9 +9746,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
work->flip_queued_vblank = drm_vblank_count(dev, intel_crtc->pipe);
work->enable_stall_check = true;
 
-   i915_gem_track_fb(work->old_fb_obj, obj,
- INTEL_FRONTBUFFER_PRIMARY(pipe));
-
intel_disable_fbc(dev);
intel_frontbuffer_flip_prepare(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7098470..bc17900 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4902,6 +4902,57 @@ unlock:
mutex_unlock(&dev_priv->drrs.mutex);
 }
 
+void intel_edp_drrs_invalidate(struct drm_device *dev,
+   unsigned frontbuffer_bits)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc;
+   enum pipe pipe;
+
+   if (!dev_priv->drrs.dp)
+   return;
+
+   mutex_lock(&dev_priv->drrs.mutex);
+   crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+   pipe = to_intel_crtc(crtc)->pipe;
+
+   if (dev_priv->drrs.refresh_rate_type == DRRS_LOW_RR) {
+   cancel_delayed_work_sync(&dev_priv->drrs.work);
+   intel_dp_set_drrs_state(dev_priv->dev,
+   dev_priv->drrs.dp->attached_connector->panel.
+   fixed_mode->vrefresh);
+   }
+
+   frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
+
+   dev_priv->drrs.busy_frontbuffer_bits |= frontbuffer_bits;
+   mutex_unlock(&dev_priv->drrs.mutex);
+}
+
+void intel_edp_drrs_flush(struct drm_device *dev,
+   unsigned frontbuffer_bits)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc;
+   enum pipe pipe;
+
+   if (!dev_priv->drrs.dp)
+   return;
+
+   mutex_lock(&dev_priv->drrs.mutex);
+   crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc;
+   pipe = to_intel_crtc(crtc)->pipe;
+   dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
+
+   cancel_delayed_work_sync(&dev_priv->drrs.work);
+
+   if (dev_priv->drrs.refresh_rate_type != DRRS_LOW_RR &&
+   !dev_priv->drrs.busy_frontbuffer_bits)
+   schedule_delayed_work(&dev_priv->drrs.work,
+   msecs_to_jiffies(1000));
+   mutex_unlock(&dev_priv->drrs.mutex);
+}
+
 static struct drm_display_mode *
 intel_dp_drrs_init(struct intel_connector *intel_connector,
struct drm_display_mode *fixed_mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1c3c25a..763c097 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1004,6 +1004,9 @@ int intel_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
 int intel_disable_plane(struct drm_plane *plane);
 void intel_edp_drrs_enable(struct intel_dp *intel_dp);
 void intel_edp_drrs_disable(struct intel_dp *intel_dp);
+void intel_edp_drrs_invalidate(struct drm_device *dev,
+   unsigned frontbuffer_bits);
+void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
 
 /* intel_dp_mst.c */
 int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int 
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/intel_frontbuffer.c
index 79f6d72..73cb6e0 10064