Re: [Intel-gfx] [PATCH] tests/gem_eio: Resilience against "hanging too fast"

[Chris Wilson]

On Wed, Nov 25, 2015 at 05:19:24PM +0100, Daniel Vetter wrote:
> Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu
> hang we need to be careful to not run into the "hanging too fast
> check":

That's not how it works. It restores the GPU by triggering a manual
reset.
-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] tests/gem_eio: Disable reset for wait subtests

[Chris Wilson]

On Wed, Nov 25, 2015 at 04:29:01PM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote:
> > This testcase tries to validate -EIO behaviour by disabling gpu reset
> > support in the kernel. Except that the wait subtest forgot to do that,
> > and therefore gets a return value of 0 instead of the expected -EIO.
> > 
> 
> Wrong. It was intentionally not using reset=false.

To be more precise, the reason here is that we are not wedging the GPU
but the expectation is that a wait upon a request that hangs reports the
hang. Since the wait on GPU activity is explicit in the ioctl, the
presumption is that the user actually cares about that activity and so
should be given greater information about how it completes (timeout, GPU
hung, or success).
-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 7/9] drm/i915: Add extra paranoia to ILK watermark calculations

[Matt Roper]

Our low-level watermark calculation functions don't get called when the
CRTC is disabled or the relevant plane is invisible, so they should
never see a zero htotal or zero bpp.  However add some checks to ensure
this is true so that we don't wind up dividing by zero if we make a
mistake elsewhere in the driver (which the atomic watermark series has
revealed we might be).

References: 
http://lists.freedesktop.org/archives/intel-gfx/2015-October/077370.html
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6efb908..d4cd5d5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1664,6 +1664,9 @@ uint32_t ilk_pipe_pixel_rate(const struct 
intel_crtc_state *pipe_config)
if (pipe_h < pfit_h)
pipe_h = pfit_h;
 
+   if (WARN_ON(!pfit_w || !pfit_h))
+   return pixel_rate;
+
pixel_rate = div_u64((uint64_t) pixel_rate * pipe_w * pipe_h,
 pfit_w * pfit_h);
}
@@ -1695,6 +1698,8 @@ static uint32_t ilk_wm_method2(uint32_t pixel_rate, 
uint32_t pipe_htotal,
 
if (WARN(latency == 0, "Latency value missing\n"))
return UINT_MAX;
+   if (WARN_ON(!pipe_htotal))
+   return UINT_MAX;
 
ret = (latency * pixel_rate) / (pipe_htotal * 1);
ret = (ret + 1) * horiz_pixels * bytes_per_pixel;
@@ -1705,6 +1710,17 @@ static uint32_t ilk_wm_method2(uint32_t pixel_rate, 
uint32_t pipe_htotal,
 static uint32_t ilk_wm_fbc(uint32_t pri_val, uint32_t horiz_pixels,
   uint8_t bytes_per_pixel)
 {
+   /*
+* Neither of these should be possible since this function shouldn't be
+* called if the CRTC is off or the plane is invisible.  But let's be
+* extra paranoid to avoid a potential divide-by-zero if we screw up
+* elsewhere in the driver.
+*/
+   if (WARN_ON(!bytes_per_pixel))
+   return 0;
+   if (WARN_ON(!horiz_pixels))
+   return 0;
+
return DIV_ROUND_UP(pri_val * 64, horiz_pixels * bytes_per_pixel) + 2;
 }
 
-- 
2.1.4

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

[Intel-gfx] [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2)

[Matt Roper]

Although we can do a good job of reading out hardware state, the
graphics firmware may have programmed the watermarks in a creative way
that doesn't match how i915 would have chosen to program them.  We
shouldn't trust the firmware's watermark programming, but should rather
re-calculate how we think WM's should be programmed and then shove those
values into the hardware.

We can do this pretty easily by creating a dummy top-level state,
running it through the check process to calculate all the values, and
then just programming the watermarks for each CRTC.

v2:  Move watermark sanitization after our BIOS fb reconstruction; the
 watermark calculations that we do here need to look at pstate->fb,
 which isn't setup yet in intel_modeset_setup_hw_state(), even
 though we have an enabled & visible plane.

Cc: Maarten Lankhorst 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/drm_atomic_helper.c  |  1 +
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c | 58 
 drivers/gpu/drm/i915/intel_pm.c  | 14 +
 4 files changed, 68 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 3731a26..8a98e0c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2478,6 +2478,7 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
}
}
 
+   drm_modeset_lock(>mode_config.connection_mutex, ctx);
drm_for_each_connector(conn, dev) {
struct drm_connector_state *conn_state;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 11ae5a5..5172604 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -630,6 +630,7 @@ struct drm_i915_display_funcs {
  struct dpll *best_clock);
int (*compute_pipe_wm)(struct intel_crtc *crtc,
   struct drm_atomic_state *state);
+   void (*program_watermarks)(struct intel_crtc_state *cstate);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 00e4c37..eb52afa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15120,6 +15120,57 @@ void intel_modeset_init_hw(struct drm_device *dev)
intel_enable_gt_powersave(dev);
 }
 
+/*
+ * Calculate what we think the watermarks should be for the state we've read
+ * out of the hardware and then immediately program those watermarks so that
+ * we ensure the hardware settings match our internal state.
+ */
+static void sanitize_watermarks(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct drm_atomic_state *state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *cstate;
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+   int i;
+
+   /* Only supported on platforms that use atomic watermark design */
+   if (!dev_priv->display.program_watermarks)
+   return;
+
+   /*
+* Calculate what we think WM's should be by creating a dummy state and
+* running it through the atomic check code.
+*/
+   drm_modeset_acquire_init(, 0);
+   state = drm_atomic_helper_duplicate_state(dev, );
+   if (WARN_ON(IS_ERR(state)))
+   return;
+
+   ret = intel_atomic_check(dev, state);
+   if (ret) {
+   /*
+* Just give up and leave watermarks untouched if we get an
+* error back from 'check'
+*/
+   DRM_DEBUG_KMS("Could not determine valid watermarks for 
inherited state\n");
+   return;
+   }
+
+   /* Write calculated watermark values back */
+   to_i915(dev)->wm.config = to_intel_atomic_state(state)->wm_config;
+   for_each_crtc_in_state(state, crtc, cstate, i) {
+   struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
+
+   dev_priv->display.program_watermarks(cs);
+   }
+
+   drm_atomic_state_free(state);
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+}
+
 void intel_modeset_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -15243,6 +15294,13 @@ void intel_modeset_init(struct drm_device *dev)
intel_dump_pipe_config(crtc, crtc->config,
   "[state after init fb reconstruction]");
}
+
+   /*
+* Make sure hardware watermarks really match the state we read out.
+* Note that we need to do this after reconstructing the BIOS fb's
+* since 

[Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks

[Matt Roper]

We've been chasing a regression[1] that prevented us from merging the last
couple patches of the ILK-style atomic watermark series.  We've finally
identified the culprit --- if we fail to reconstruct the BIOS FB, our internal
driver state was left in an inconsistent state which caused confusion for the
watermark code.  Here's a series that collects that fix (along with a couple
other bugfixes that were found while debugging), a few debugging enhancements,
and the completion of the ILK atomic watermark series.

 * The first patch in this series addresses that issue and
   ensures that we cleanly turn off the primary plane if we're unable to inherit
   the framebuffer.  
 * Patches 2-4 just clarify/expand some of the information dumped by the
   driver while debugging.
 * Patches 5 and 6 fix two additional bugs that were discovered while
   searching for the cause of the regression.
 * Patch 7 just adds some extra paranoia and invariant checking to the
   watermark code.
 * Patches 8 and 9 are the two final patches from the original atomic watermark
   series; with the fixes earlier in the series, we've confirmed that they no
   longer cause regressions on Jani's machine.

[1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077113.html

Matt Roper (9):
  drm/i915: Disable primary plane if we fail to reconstruct BIOS fb
  drm/i915: Dump in-flight plane state while dumping in-flight CRTC
state
  drm/i915: Clarify plane state during CRTC state dumps (v2)
  drm/i915: Dump pipe config after initial FB is reconstructed
  drm/i915: Setup clipped src/dest coordinates during FB reconstruction
(v2)
  drm/i915: Convert hsw_compute_linetime_wm to use in-flight state
  drm/i915: Add extra paranoia to ILK watermark calculations
  drm/i915: Sanitize watermarks after hardware state readout (v2)
  drm/i915: Add two-stage ILK-style watermark programming (v7)

 drivers/gpu/drm/drm_atomic_helper.c  |   1 +
 drivers/gpu/drm/i915/i915_drv.h  |   5 +
 drivers/gpu/drm/i915/intel_atomic.c  |   1 +
 drivers/gpu/drm/i915/intel_display.c | 195 +--
 drivers/gpu/drm/i915/intel_drv.h |  31 +-
 drivers/gpu/drm/i915/intel_pm.c  | 186 -
 6 files changed, 359 insertions(+), 60 deletions(-)

-- 
2.1.4

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

[Intel-gfx] [PATCH 3/5] scripts/kernel-doc: Improve Markdown results

[Daniel Vetter]

From: Danilo Cesar Lemes de Paula 

Using pandoc as the Markdown engine cause some minor side effects as
pandoc includes  main  tags for almost everything.
Original Markdown support approach removes those main tags, but it caused
some inconsistencies when that tag is not the main one, like:
..
...

As kernel-doc was already including a  tag, it causes the presence
of double  tags (), which is not supported by DocBook
spec.

Html target gets away with it, so it causes no harm, although other
targets might not be so lucky (pdf as example).

We're now delegating the inclusion of the main  tag to pandoc
only, as it knows when it's necessary or not.

That behavior causes a corner case, the only situation where we're
certainly that  is not needed, which is the  content.
For those cases, we're using a $output_markdown_nopara = 1 control var.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
Cc: Graham Whaley 
---
 scripts/kernel-doc | 48 ++--
 1 file changed, 34 insertions(+), 14 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 28737053395a..e01e74f15a22 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -288,6 +288,7 @@ my $use_markdown = 0;
 my $verbose = 0;
 my $output_mode = "man";
 my $output_preformatted = 0;
+my $output_markdown_nopara = 0;
 my $no_doc_sections = 0;
 my @highlights = @highlights_man;
 my $blankline = $blankline_man;
@@ -538,8 +539,11 @@ sub markdown_to_docbook {
close(CHLD_OUT);
close(CHLD_ERR);
 
-   # pandoc insists in adding Main , we should remove them.
-   $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
+   if ($output_markdown_nopara) {
+   # pandoc insists in adding Main , sometimes we
+   # want to remove them.
+   $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
+   }
 
return $content;
 }
@@ -614,7 +618,7 @@ sub output_highlight {
$line =~ s/^\s*//;
}
if ($line eq ""){
-   if (! $output_preformatted) {
+   if (! $output_preformatted && ! $use_markdown) {
print $lineprefix, local_unescape($blankline);
}
} else {
@@ -1035,7 +1039,7 @@ sub output_section_xml(%) {
# programlisting is already included by pandoc
print "\n" unless $use_markdown;
$output_preformatted = 1;
-   } else {
+   } elsif (! $use_markdown) {
print "\n";
}
output_highlight($args{'sections'}{$section});
@@ -1043,7 +1047,7 @@ sub output_section_xml(%) {
if ($section =~ m/EXAMPLE/i) {
print "\n" unless $use_markdown;
print "\n";
-   } else {
+   } elsif (! $use_markdown) {
print "\n";
}
print "\n";
@@ -1075,7 +1079,9 @@ sub output_function_xml(%) {
 print " " . $args{'function'} . "\n";
 print " \n";
 print "  ";
+$output_markdown_nopara = 1;
 output_highlight ($args{'purpose'});
+$output_markdown_nopara = 0;
 print " \n";
 print "\n";
 
@@ -1113,10 +1119,12 @@ sub output_function_xml(%) {
$parameter_name =~ s/\[.*//;
 
print "  \n   
$parameter\n";
-   print "   \n\n";
+   print "   \n";
+   print "\n" unless $use_markdown;
$lineprefix=" ";
output_highlight($args{'parameterdescs'}{$parameter_name});
-   print "\n   \n  \n";
+   print "\n" unless $use_markdown;
+   print "   \n  \n";
}
print " \n";
 } else {
@@ -1152,7 +1160,9 @@ sub output_struct_xml(%) {
 print " " . $args{'type'} . " " . $args{'struct'} . 
"\n";
 print " \n";
 print "  ";
+$output_markdown_nopara = 1;
 output_highlight ($args{'purpose'});
+$output_markdown_nopara = 0;
 print " \n";
 print "\n";
 
@@ -1205,9 +1215,11 @@ sub output_struct_xml(%) {
   ($args{'parameterdescs'}{$parameter_name} ne $undescribed) || next;
   print "";
   print "  $parameter\n";
-  print "  \n";
+  print "  \n";
+  print " \n" unless $use_markdown;
   output_highlight($args{'parameterdescs'}{$parameter_name});
-  print "  \n";
+  print " \n" unless $use_markdown;
+  print "  \n";
   print "\n";
 }
 print "  \n";
@@ -1246,7 +1258,9 @@ sub output_enum_xml(%) {
 print " enum " . 

[Intel-gfx] [PATCH 4/5] scripts/kernel-doc: Use asciidoc instead of markdown

[Daniel Vetter]

By popular demand.

This needs some adjustment/fixups after feeding snippets to asciidoc
since compared to markdown asciidown escapes xml markup and doesn't
just let it through.

The other noticeable change is that build times increase a lot - we
need to launch the markup process per-snippet, there's a few thousand
of them and asciidoc (python) has a substantial higher overhead per
invocation than pandoc (haskell).

Cc: Danilo Cesar Lemes de Paula 
Cc: Thomas Wood 
Cc: Jonathan Corbet 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/Makefile |  6 +++---
 scripts/kernel-doc | 12 +++-
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 246ad38550e5..5335955c0de5 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -104,8 +104,8 @@ define rule_docproc
 endef
 
 %.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
-   @(which pandoc > /dev/null 2>&1) || \
-   (echo "*** To get propper documentation you need to install pandoc 
***";)
+   @(which asciidoc > /dev/null 2>&1) || \
+   (echo "*** To get propper documentation you need to install asciidoc 
***";)
$(call if_changed_rule,docproc)
 
 # Tell kbuild to always build the programs
@@ -116,7 +116,7 @@ notfoundtemplate = echo "*** You have to install 
docbook-utils or xmlto ***"; \
 db2xtemplate = db2TYPE -o $(dir $@) $<
 xmltotemplate = xmlto TYPE $(XMLTOFLAGS) -o $(dir $@) $<
 
-ifneq ($(shell which pandoc >/dev/null 2>&1 && echo found),found)
+ifneq ($(shell which asciidoc >/dev/null 2>&1 && echo found),found)
MARKDOWNREADY := "";
 endif
 
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index e01e74f15a22..c8eed5299a4b 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -524,7 +524,7 @@ sub dump_doc_section {
 sub markdown_to_docbook {
my $orig_content = $_[0];
 
-   my $pid = open3( \*CHLD_IN, \*CHLD_OUT, \*CHLD_ERR, "pandoc  
--columns=80 -f markdown -t docbook" );
+   my $pid = open3( \*CHLD_IN, \*CHLD_OUT, \*CHLD_ERR, "asciidoc  
--no-header-footer --backend=docbook45 -" );
 
print CHLD_IN "$orig_content";
close(CHLD_IN);
@@ -605,6 +605,16 @@ sub output_highlight {
 #   print STDERR "contents af:$contents\n";
 if ($use_markdown) {
 $contents = markdown_to_docbook($contents);
+
+   # Compared to markdown asciidoc doesn't let through arbitrary xml
+   # markup. We need to un-escape the kerneldoc markup for functions,
+   # structures, ...
+   $contents =~ s/quote(\S*)\/quote/$1<\/quote>/g;
+   $contents =~ 
s/constant(\S*)\/constant/$1<\/constant>/g;
+   $contents =~ 
s/structname(\S*)\/structname/$1<\/structname>/g;
+   $contents =~ 
s/parameter(\S*)\/parameter/$1<\/parameter>/g;
+   $contents =~ 
s/function(\S*)\/function/$1<\/function>/g;
+   $contents =~ s/envar(\S*)\/envar/$1<\/envar>/g;
 }
 
 #   strip whitespaces when generating html5
-- 
2.5.1

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

[Intel-gfx] [PATCH] tests/gem_eio: Resilience against "hanging too fast"

[Daniel Vetter]

Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu
hang we need to be careful to not run into the "hanging too fast
check":

- don't restore the ban period, but instead keep it at 0.
- make sure we idle the gpu fully before hanging it again (wait
  subtest missted that).

With this gem_eio works now reliable even when I don't run the
subtests individually.

Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 tests/gem_eio.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index ad67332eae59..f6e41db63a7d 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -84,13 +84,17 @@ static void trigger_reset(int fd)
 
 static void wedge_gpu(int fd)
 {
+   igt_hang_ring_t hang;
+
/* First idle the GPU then disable GPU resets before injecting a hang */
gem_quiescent_gpu(fd);
 
igt_require(i915_reset_control(false));
 
igt_debug("Wedging GPU by injecting hang\n");
-   igt_post_hang_ring(fd, igt_hang_ring(fd, I915_EXEC_DEFAULT));
+   hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
+   hang.ban = 0;
+   igt_post_hang_ring(fd, hang);
 
igt_assert(i915_reset_control(true));
 }
@@ -161,10 +165,14 @@ static void test_wait(int fd)
 {
igt_hang_ring_t hang;
 
+   /* First idle the GPU then disable GPU resets before injecting a hang */
+   gem_quiescent_gpu(fd);
+
igt_require(i915_reset_control(false));
 
hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
igt_assert_eq(__gem_wait(fd, hang.handle, -1), -EIO);
+   hang.ban = 0;
igt_post_hang_ring(fd, hang);
 
igt_assert(i915_reset_control(true));
-- 
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: Add some more bits to CURSOR_POS_MASK

[Patrik Jakobsson]

On Wed, Nov 25, 2015 at 1:54 PM, Robert Fekete
 wrote:
> On ons, 2015-11-18 at 10:17 +0100, Daniel Vetter wrote:
>> On Wed, Nov 04, 2015 at 10:59:28AM +0100, Patrik Jakobsson wrote:
>> > On Wed, Nov 04, 2015 at 10:35:19AM +0100, Robert Fekete wrote:
>> > > The old value of 0x7FF will wrap the position at 2048 giving wrong
>> > > coordinate values on panels larger than 2048 pixels in any direction.
>> > > Used in i915_debugfs atm. Looking at all hw specs available at 01.org
>> > > shows that X position is bit 0:11, and even 0:12 on some hw where
>> > > remaining bits up to bit 14 is MBZ. For Y position it is bits 16-27
>> > > where bits 28:30 is MBZ. It should be safe to increase CURSOR_POS_MASK
>> > > to 13 bits (0x1FFF) making 8192 as a new wrap around value still getting
>> > > valid cursor positions on platforms with only 12bits available thanks to
>> > > MBZ on adjacent bits above.
>> >
>> > I cannot find documentation for older hardware and this only touches
>> > debugfs, so in worst case we get wrong values for really old hardware but 
>> > good
>> > ones for newer. I think that's a fair tradeoff.
>> >
>> > Reviewed-by: Patrik Jakobsson 
>>
>> If it's only used in debugfs then imo just drop it. Having a _MASK which
>> isn't valid on all platforms, but where we don't have differnt #defines
>> for the different platforms is really confusing.
>> -Daniel

Yes, seems fair.

>
> Well, not the most important patch around, but still the value of 0x7ff
> is still too conservative and gives wrong cursor pos values on large
> panels. I have hard times digging up really old register specs so I
> still can't see which Intel platform this new value of mine isn't valid
> on.

I think Daniel meant that we can remove the define altogether and
hardcode a sane mask in debugfs instead. Keeping the define around
might give people the wrong idea what the bspec actually says. Also
adding a comment along with the hardcoded mask in debugfs would be
nice.

-Patrik

>
> It is this patch by Chris in debugfs that is broken on large panels
> wrapping coords at (x_pos/y_pos > 2048)
> http://marc.info/?l=git-commits-head=139697989108096=1
>
>> >
>> > >
>> > > Signed-off-by: Robert Fekete 
>> > > ---
>> > >  drivers/gpu/drm/i915/i915_reg.h | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> > > b/drivers/gpu/drm/i915/i915_reg.h
>> > > index 894253228947..f351f46f8cb9 100644
>> > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > @@ -4883,7 +4883,7 @@ enum skl_disp_power_wells {
>> > >  #define   CURSOR_TRICKLE_FEED_DISABLE(1 << 14)
>> > >  #define _CURABASE0x70084
>> > >  #define _CURAPOS 0x70088
>> > > -#define   CURSOR_POS_MASK   0x007FF
>> > > +#define   CURSOR_POS_MASK   0x01FFF
>> > >  #define   CURSOR_POS_SIGN   0x8000
>> > >  #define   CURSOR_X_SHIFT0
>> > >  #define   CURSOR_Y_SHIFT16
>> > > --
>> > > 1.9.1
>> > >
>> > > ___
>> > > 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
>>
>
> --
> BR
> /Robert Fekete
> Intel Open Source Technology Center
>
> ___
> 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 0/5] Better markup for GPU DocBook

[Daniel Vetter]

Hi all,

As you might know the markup improvements have been discussed at kernel summit:

https://lwn.net/Articles/662930/

Unfortunately it died in a bikeshed fest due to an alliance of people who think
docs are useless and you should just read code and others who didn't know how to
build the kerneldoc into something pretty. Oh well.

But I still want this, and Dave Airlie is ok with using it for drm kerneldoc as
long as I maintain the support. Plan is to merge the first patch to adjust
gpu.tmpl into drm properly, and keep everything else in topic/kerneldoc at

git://anongit.freedesktop.org/drm-intel topic/kerneldoc

If you want to build pretty docs just install asciidoc and base your drm
documentation patches on top of drm-intel-nightly. That tree also includes all
of Dave's tree. Alternatively pull in the above topic branch.

Note that asciidoc is strictly optional, but without it the docbook will look a
bit bad since beyond paragraphs there won't be any additional formatting (like
tables, quoting for sourcecode snippets or lists).

Intel also has an autobuilder that pushes latest drm-intel-nightly docs to

http://dri.freedesktop.org/docs/drm/

Cheers, Daniel

Daniel Vetter (2):
  scripts/kernel-doc: Use asciidoc instead of markdown
  drm: Enable markdown^Wasciidoc for gpu.tmpl

Danilo Cesar Lemes de Paula (3):
  drm/doc: Convert to markdown
  scripts/kernel-doc: Adding infrastructure for markdown support
  scripts/kernel-doc: Improve Markdown results

 Documentation/DocBook/Makefile |  25 +---
 Documentation/DocBook/gpu.tmpl |  86 --
 drivers/gpu/drm/drm_modes.c|  12 ++--
 drivers/gpu/drm/drm_modeset_lock.c |  14 ++---
 drivers/gpu/drm/drm_prime.c|  16 ++---
 drivers/gpu/drm/i915/i915_reg.h|  48 +++
 scripts/docproc.c  |  54 -
 scripts/kernel-doc | 120 -
 8 files changed, 203 insertions(+), 172 deletions(-)

-- 
2.5.1

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

[Intel-gfx] [PATCH 1/5] drm/doc: Convert to markdown

[Daniel Vetter]

From: Danilo Cesar Lemes de Paula 

DRM Docbook is now Markdown ready. This means its doc is able to
use markdown text on it.

* Documentation/DocBook/drm.tmpl: Contains a table duplicated from
  drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore

* drivers/gpu/drm/drm_modeset_lock.c: had a code example that used
  to look pretty bad on html. Fixed by using proper code markup.

* drivers/gpu/drm/drm_prime.c: Remove spaces between lines to make
  a proper markup list.

* drivers/gpu/drm/i915/i915_reg.h: Altought pandoc supports tables,
  it doesn't support table cell spanning. But we can use fixed-width
  for those special cases.

* include/drm/drm_vma_manager.h: Another code example that should be
  proper indented with four spaces.

v2 (Daniel): Adjust name to gpu.xml due to rename.

v3 (Daniel):
Split out the actual enabling in the Makefile - this way we can merge
the conversion, while just keeping the enabling in a drm-private tree.

Signed-off-by: Danilo Cesar Lemes de Paula  (v1)
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/gpu.tmpl | 86 --
 drivers/gpu/drm/drm_modes.c| 12 +++---
 drivers/gpu/drm/drm_modeset_lock.c | 14 +++
 drivers/gpu/drm/drm_prime.c| 16 +++
 drivers/gpu/drm/i915/i915_reg.h| 48 ++---
 5 files changed, 42 insertions(+), 134 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 201dcd3c2e9d..c05d7df3067d 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -4039,92 +4039,6 @@ int num_ioctls;
   
 DPIO
 !Pdrivers/gpu/drm/i915/i915_reg.h DPIO
-   
- Dual channel PHY (VLV/CHV/BXT)
- 
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
-   
- 
-   CH0
-   CH1
- 
-   
-   
- 
-   CMN/PLL/REF
-   CMN/PLL/REF
- 
- 
-   PCS01
-   PCS23
-   PCS01
-   PCS23
- 
- 
-   TX0
-   TX1
-   TX2
-   TX3
-   TX0
-   TX1
-   TX2
-   TX3
- 
- 
-   DDI0
-   DDI1
- 
-   
- 
-   
-   
- Single channel PHY (CHV/BXT)
- 
-   
-   
-   
-   
-   
-   
-   
-   
- 
-   CH0
- 
-   
-   
- 
-   CMN/PLL/REF
- 
- 
-   PCS01
-   PCS23
- 
- 
-   TX0
-   TX1
-   TX2
-   TX3
- 
- 
-   DDI2
- 
-   
- 
-   
   
 
   
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index cd74a0953f42..9480464434cf 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -553,10 +553,10 @@ EXPORT_SYMBOL(drm_gtf_mode_complex);
  * drivers/video/fbmon.c
  *
  * Standard GTF parameters:
- * M = 600
- * C = 40
- * K = 128
- * J = 20
+ * M = 600
+ * C = 40
+ * K = 128
+ * J = 20
  *
  * Returns:
  * The modeline based on the GTF algorithm stored in a drm_display_mode object.
@@ -1212,7 +1212,7 @@ EXPORT_SYMBOL(drm_mode_connector_list_update);
  * This uses the same parameters as the fb modedb.c, except for an extra
  * force-enable, force-enable-digital and force-disable bit at the end:
  *
- * x[M][R][-][@][i][m][eDd]
+ * x[M][R][-][@][i][m][eDd]
  *
  * The intermediate drm_cmdline_mode structure is required to store additional
  * options from the command line modline like the force-enable/disable flag.
@@ -1491,4 +1491,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
 
 out:
return ret;
-}
\ No newline at end of file
+}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index 6675b1428410..7c9ca2381d78 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -40,17 +40,15 @@
  * The basic usage pattern 

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7)

[Ville Syrjälä]

On Wed, Nov 25, 2015 at 08:48:35AM -0800, Matt Roper wrote:
> In addition to calculating final watermarks, let's also pre-calculate a
> set of intermediate watermark values at atomic check time.  These
> intermediate watermarks are a combination of the watermarks for the old
> state and the new state; they should satisfy the requirements of both
> states which means they can be programmed immediately when we commit the
> atomic state (without waiting for a vblank).  Once the vblank does
> happen, we can then re-program watermarks to the more optimal final
> value.
> 
> v2: Significant rebasing/rewriting.
> 
> v3:
>  - Move 'need_postvbl_update' flag to CRTC state (Daniel)
>  - Don't forget to check intermediate watermark values for validity
>(Maarten)
>  - Don't due async watermark optimization; just do it at the end of the
>atomic transaction, after waiting for vblanks.  We do want it to be
>async eventually, but adding that now will cause more trouble for
>Maarten's in-progress work.  (Maarten)
>  - Don't allocate space in crtc_state for intermediate watermarks on
>platforms that don't need it (gen9+).
>  - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
>now that ilk_update_wm is gone.
> 
> v4:
>  - Add a wm_mutex to cover updates to intel_crtc->active and the
>need_postvbl_update flag.  Since we don't have async yet it isn't
>terribly important yet, but might as well add it now.
>  - Change interface to program watermarks.  Platforms will now expose
>.initial_watermarks() and .optimize_watermarks() functions to do
>watermark programming.  These should lock wm_mutex, copy the
>appropriate state values into intel_crtc->active, and then call
>the internal program watermarks function.
> 
> v5:
>  - Skip intermediate watermark calculation/check during initial hardware
>readout since we don't trust the existing HW values (and don't have
>valid values of our own yet).
>  - Don't try to call .optimize_watermarks() on platforms that don't have
>atomic watermarks yet.  (Maarten)
> 
> v6:
>  - Rebase
> 
> v7:
>  - Further rebase
> 
> Signed-off-by: Matt Roper 
> Reviewed-by(v5): Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   6 +-
>  drivers/gpu/drm/i915/intel_atomic.c  |   1 +
>  drivers/gpu/drm/i915/intel_display.c |  90 +++-
>  drivers/gpu/drm/i915/intel_drv.h |  31 ++-
>  drivers/gpu/drm/i915/intel_pm.c  | 160 
> ---
>  5 files changed, 232 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5172604..427b488 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -630,7 +630,11 @@ struct drm_i915_display_funcs {
> struct dpll *best_clock);
>   int (*compute_pipe_wm)(struct intel_crtc *crtc,
>  struct drm_atomic_state *state);
> - void (*program_watermarks)(struct intel_crtc_state *cstate);
> + int (*compute_intermediate_wm)(struct drm_device *dev,
> +struct intel_crtc *intel_crtc,
> +struct intel_crtc_state *newstate);
> + void (*initial_watermarks)(struct intel_crtc_state *cstate);
> + void (*optimize_watermarks)(struct intel_crtc_state *cstate);
>   void (*update_wm)(struct drm_crtc *crtc);
>   int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
>   void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 643f342..b91e166 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -95,6 +95,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>  
>   crtc_state->update_pipe = false;
>   crtc_state->disable_lp_wm = false;
> + crtc_state->wm.need_postvbl_update = false;
>  
>   return _state->base;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index eb52afa..8db0486 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11801,6 +11801,12 @@ int intel_plane_atomic_calc_changes(struct 
> drm_crtc_state *crtc_state,
>   intel_crtc->atomic.update_wm_pre = true;
>   }
>  
> + /* Pre-gen9 platforms need two-step watermark updates */
> + if ((intel_crtc->atomic.update_wm_pre || 
> intel_crtc->atomic.update_wm_post) &&
> + INTEL_INFO(dev)->gen < 9 &&
> + dev_priv->display.optimize_watermarks)
> + to_intel_crtc_state(crtc_state)->wm.need_postvbl_update = true;
> +
>   if (visible || was_visible)
>   intel_crtc->atomic.fb_bits |=
>   to_intel_plane(plane)->frontbuffer_bit;
> @@ -11957,8 

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request

[Chris Wilson]

On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote:
> > The wait-request interface still has the wait-seqno legacy of having to
> > acquire the reset_counter under the mutex before calling. That is quite
> > hairy and causes a major complication later where we want to amalgamate
> > waiters.
> 
> Yeah, that's a sensible change. But since I don't yet understand where
> exactly the current logic results in a wedge gpu I can't convince myself
> that the new one is ok.

Just to show where I am going with the interface change and why I think
it so important (other than it removes a hairy dance that we've have had
to copy all around the code):

http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly=75e73616f72f14ab82037adb1b2b054e2e500c21
-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 5/5] drm: Enable markdown^Wasciidoc for gpu.tmpl

[Daniel Vetter]

Unfortunately the entire improved docbook project died at KS in a
massive bikeshed. So we need to carry this around in drm private trees
forever :(

I discussed this with Dave at kernel summit and he's ok with this.

I'll maintain the asciidoc support in topic/kerneldoc in the
drm-intel.git tree. There's an autobuilder that pushes
drm-intel-nightly (which includes all of Dave's trees) to

http://dri.freedesktop.org/docs/drm/

Thomas Wood keeps care of that autobuilder, so please ping him if
there's something amiss.

Note that asciidoc is optional - all the kerneldoc comment layout
rules are the same, those bits landed in 4.4. It will simply not quite
look as pretty if you don't have it installed.

Cc: Dave Airlie 
Cc: Thomas Wood 
Cc: Jonathan Corbet 
Acked-by: Dave Airlie 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 5335955c0de5..b655343631cf 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -17,7 +17,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
 
-MARKDOWNREADY := 
+MARKDOWNREADY := gpu.xml
 
 include Documentation/DocBook/media/Makefile
 
-- 
2.5.1

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

[Intel-gfx] [PATCH 2/5] scripts/kernel-doc: Adding infrastructure for markdown support

[Daniel Vetter]

From: Danilo Cesar Lemes de Paula 

Markdown support is given by calling an external tool, pandoc, for all
highlighted text on kernel-doc.

Pandoc converts Markdown text to proper Docbook tags, which will be
later translated to pdf, html or other targets.

This adds the capability of adding human-readle text highlight (bold,
underline, etc), bullet and numbered lists, simple tables, fixed-width
text (including asciiart), requiring minimal changes to current
documentation.

At this moment, pandoc is totally optional. Docbooks ready for markdown
should be added to the MARKDOWNREADY variable inside the Makefile. In
case the developer doesn't have pandoc installed, Make will throw a
warning and the documentation build will continue, generating
simple Documentation without the features brought by pandoc.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Randy Dunlap 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Cc: Jonathan Corbet 
Cc: Herbert Xu 
Cc: Stephan Mueller 
Cc: Michal Marek 
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 Documentation/DocBook/Makefile | 25 +++-
 scripts/docproc.c  | 54 --
 scripts/kernel-doc | 66 --
 3 files changed, 119 insertions(+), 26 deletions(-)

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 91f6d89bb19f..246ad38550e5 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -17,6 +17,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
 
+MARKDOWNREADY := 
+
 include Documentation/DocBook/media/Makefile
 
 ###
@@ -87,18 +89,23 @@ XMLTOFLAGS += --skip-validation
 # The following rules are used to generate the .xml documentation
 # required to generate the final targets. (ps, pdf, html).
 quiet_cmd_docproc = DOCPROC $@
-  cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $< >$@
+  cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $<
 define rule_docproc
-   set -e; \
-$(if $($(quiet)cmd_$(1)),echo '  $($(quiet)cmd_$(1))';)\
-$(cmd_$(1));   \
-(  \
-  echo 'cmd_$@ := $(cmd_$(1))';\
-  echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`;  \
+   set -e; 
\
+   USEMARKDOWN=""; 
\
+   FILE=`basename $@`; 
\
+   [[ "$(MARKDOWNREADY)" =~ "$${FILE}" ]] && USEMARKDOWN="-use-markdown";  
\
+$(if $($(quiet)cmd_$(1)),echo '  $($(quiet)cmd_$(1))';)
\
+$(cmd_$(1)) $$USEMARKDOWN >$@; 
\
+(  
\
+  echo 'cmd_$@ := $(cmd_$(1))';
\
+  echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`;  
\
 ) > $(dir $@).$(notdir $@).cmd
 endef
 
 %.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
+   @(which pandoc > /dev/null 2>&1) || \
+   (echo "*** To get propper documentation you need to install pandoc 
***";)
$(call if_changed_rule,docproc)
 
 # Tell kbuild to always build the programs
@@ -109,6 +116,10 @@ notfoundtemplate = echo "*** You have to install 
docbook-utils or xmlto ***"; \
 db2xtemplate = db2TYPE -o $(dir $@) $<
 xmltotemplate = xmlto TYPE $(XMLTOFLAGS) -o $(dir $@) $<
 
+ifneq ($(shell which pandoc >/dev/null 2>&1 && echo found),found)
+   MARKDOWNREADY := "";
+endif
+
 # determine which methods are available
 ifeq ($(shell which db2ps >/dev/null 2>&1 && echo found),found)
use-db2x = db2x
diff --git a/scripts/docproc.c b/scripts/docproc.c
index e267e621431a..7c6b225a6a50 100644
--- a/scripts/docproc.c
+++ b/scripts/docproc.c
@@ -73,12 +73,15 @@ FILELINE * docsection;
 #define NOFUNCTION"-nofunction"
 #define NODOCSECTIONS "-no-doc-sections"
 #define SHOWNOTFOUND  "-show-not-found"
+#define USEMARKDOWN   "-use-markdown"
 
 static char *srctree, *kernsrctree;
 
 static char **all_list = NULL;
 static int all_list_len = 0;
 
+static int use_markdown = 0;
+
 static void consume_symbol(const char *sym)
 {
int i;
@@ -95,10 +98,11 @@ static void 

Re: [Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks

[Ville Syrjälä]

On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote:
> We've been chasing a regression[1] that prevented us from merging the last
> couple patches of the ILK-style atomic watermark series.  We've finally
> identified the culprit --- if we fail to reconstruct the BIOS FB, our internal
> driver state was left in an inconsistent state which caused confusion for the
> watermark code.  Here's a series that collects that fix (along with a couple
> other bugfixes that were found while debugging), a few debugging enhancements,
> and the completion of the ILK atomic watermark series.
> 
>  * The first patch in this series addresses that issue and
>ensures that we cleanly turn off the primary plane if we're unable to 
> inherit
>the framebuffer.  
>  * Patches 2-4 just clarify/expand some of the information dumped by the
>driver while debugging.
>  * Patches 5 and 6 fix two additional bugs that were discovered while
>searching for the cause of the regression.
>  * Patch 7 just adds some extra paranoia and invariant checking to the
>watermark code.
>  * Patches 8 and 9 are the two final patches from the original atomic 
> watermark
>series; with the fixes earlier in the series, we've confirmed that they no
>longer cause regressions on Jani's machine.
> 
> [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077113.html

Quickly skimmed through the series to see if there was a fix to
the "merging optimal wms instead of merging active wms like we
should" bug we have in the current code right now. Nothing
relevant caught my eye at least.

> 
> Matt Roper (9):
>   drm/i915: Disable primary plane if we fail to reconstruct BIOS fb
>   drm/i915: Dump in-flight plane state while dumping in-flight CRTC
> state
>   drm/i915: Clarify plane state during CRTC state dumps (v2)
>   drm/i915: Dump pipe config after initial FB is reconstructed
>   drm/i915: Setup clipped src/dest coordinates during FB reconstruction
> (v2)
>   drm/i915: Convert hsw_compute_linetime_wm to use in-flight state
>   drm/i915: Add extra paranoia to ILK watermark calculations
>   drm/i915: Sanitize watermarks after hardware state readout (v2)
>   drm/i915: Add two-stage ILK-style watermark programming (v7)
> 
>  drivers/gpu/drm/drm_atomic_helper.c  |   1 +
>  drivers/gpu/drm/i915/i915_drv.h  |   5 +
>  drivers/gpu/drm/i915/intel_atomic.c  |   1 +
>  drivers/gpu/drm/i915/intel_display.c | 195 
> +--
>  drivers/gpu/drm/i915/intel_drv.h |  31 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 186 -
>  6 files changed, 359 insertions(+), 60 deletions(-)
> 
> -- 
> 2.1.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] tests/gem_eio: Disable reset for wait subtests

[Daniel Vetter]

This testcase tries to validate -EIO behaviour by disabling gpu reset
support in the kernel. Except that the wait subtest forgot to do that,
and therefore gets a return value of 0 instead of the expected -EIO.

With this fix gem_eio passes on a kernel with my fixes completely.

Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 tests/gem_eio.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index a24c8f1c53b5..ad67332eae59 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -161,10 +161,14 @@ static void test_wait(int fd)
 {
igt_hang_ring_t hang;
 
+   igt_require(i915_reset_control(false));
+
hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
igt_assert_eq(__gem_wait(fd, hang.handle, -1), -EIO);
igt_post_hang_ring(fd, hang);
 
+   igt_assert(i915_reset_control(true));
+
trigger_reset(fd);
 }
 
-- 
2.1.0

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

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Sanitize watermarks after hardware state readout (v2)

[Ville Syrjälä]

On Wed, Nov 25, 2015 at 08:48:34AM -0800, Matt Roper wrote:
> Although we can do a good job of reading out hardware state, the
> graphics firmware may have programmed the watermarks in a creative way
> that doesn't match how i915 would have chosen to program them.  We
> shouldn't trust the firmware's watermark programming, but should rather
> re-calculate how we think WM's should be programmed and then shove those
> values into the hardware.
> 
> We can do this pretty easily by creating a dummy top-level state,
> running it through the check process to calculate all the values, and
> then just programming the watermarks for each CRTC.
> 
> v2:  Move watermark sanitization after our BIOS fb reconstruction; the
>  watermark calculations that we do here need to look at pstate->fb,
>  which isn't setup yet in intel_modeset_setup_hw_state(), even
>  though we have an enabled & visible plane.
> 
> Cc: Maarten Lankhorst 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c  |  1 +
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/intel_display.c | 58 
> 
>  drivers/gpu/drm/i915/intel_pm.c  | 14 +
>  4 files changed, 68 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3731a26..8a98e0c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2478,6 +2478,7 @@ drm_atomic_helper_duplicate_state(struct drm_device 
> *dev,
>   }
>   }
>  
> + drm_modeset_lock(>mode_config.connection_mutex, ctx);
>   drm_for_each_connector(conn, dev) {
>   struct drm_connector_state *conn_state;
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 11ae5a5..5172604 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -630,6 +630,7 @@ struct drm_i915_display_funcs {
> struct dpll *best_clock);
>   int (*compute_pipe_wm)(struct intel_crtc *crtc,
>  struct drm_atomic_state *state);
> + void (*program_watermarks)(struct intel_crtc_state *cstate);
>   void (*update_wm)(struct drm_crtc *crtc);
>   int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
>   void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 00e4c37..eb52afa 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15120,6 +15120,57 @@ void intel_modeset_init_hw(struct drm_device *dev)
>   intel_enable_gt_powersave(dev);
>  }
>  
> +/*
> + * Calculate what we think the watermarks should be for the state we've read
> + * out of the hardware and then immediately program those watermarks so that
> + * we ensure the hardware settings match our internal state.
> + */
> +static void sanitize_watermarks(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_atomic_state *state;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *cstate;
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> + int i;
> +
> + /* Only supported on platforms that use atomic watermark design */
> + if (!dev_priv->display.program_watermarks)
> + return;
> +
> + /*
> +  * Calculate what we think WM's should be by creating a dummy state and
> +  * running it through the atomic check code.
> +  */
> + drm_modeset_acquire_init(, 0);
> + state = drm_atomic_helper_duplicate_state(dev, );
> + if (WARN_ON(IS_ERR(state)))
> + return;
> +
> + ret = intel_atomic_check(dev, state);
> + if (ret) {
> + /*
> +  * Just give up and leave watermarks untouched if we get an
> +  * error back from 'check'
> +  */
> + DRM_DEBUG_KMS("Could not determine valid watermarks for 
> inherited state\n");
> + return;
> + }
> +
> + /* Write calculated watermark values back */
> + to_i915(dev)->wm.config = to_intel_atomic_state(state)->wm_config;
> + for_each_crtc_in_state(state, crtc, cstate, i) {
> + struct intel_crtc_state *cs = to_intel_crtc_state(cstate);
> +
> + dev_priv->display.program_watermarks(cs);
> + }
> +
> + drm_atomic_state_free(state);
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +}
> +
>  void intel_modeset_init(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -15243,6 +15294,13 @@ void intel_modeset_init(struct drm_device *dev)
>   intel_dump_pipe_config(crtc, crtc->config,
>  "[state after init fb 

Re: [Intel-gfx] [PATCH 0/9] Wrap up ILK-style atomic watermarks

[Matt Roper]

On Wed, Nov 25, 2015 at 07:00:11PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote:
> > We've been chasing a regression[1] that prevented us from merging the last
> > couple patches of the ILK-style atomic watermark series.  We've finally
> > identified the culprit --- if we fail to reconstruct the BIOS FB, our 
> > internal
> > driver state was left in an inconsistent state which caused confusion for 
> > the
> > watermark code.  Here's a series that collects that fix (along with a couple
> > other bugfixes that were found while debugging), a few debugging 
> > enhancements,
> > and the completion of the ILK atomic watermark series.
> > 
> >  * The first patch in this series addresses that issue and
> >ensures that we cleanly turn off the primary plane if we're unable to 
> > inherit
> >the framebuffer.  
> >  * Patches 2-4 just clarify/expand some of the information dumped by the
> >driver while debugging.
> >  * Patches 5 and 6 fix two additional bugs that were discovered while
> >searching for the cause of the regression.
> >  * Patch 7 just adds some extra paranoia and invariant checking to the
> >watermark code.
> >  * Patches 8 and 9 are the two final patches from the original atomic 
> > watermark
> >series; with the fixes earlier in the series, we've confirmed that they 
> > no
> >longer cause regressions on Jani's machine.
> > 
> > [1] http://lists.freedesktop.org/archives/intel-gfx/2015-October/077113.html
> 
> Quickly skimmed through the series to see if there was a fix to
> the "merging optimal wms instead of merging active wms like we
> should" bug we have in the current code right now. Nothing
> relevant caught my eye at least.

I'm not sure I'm aware of this problem; is there a bugzilla or mailing
list thread that describes the issue?


Matt

> 
> > 
> > Matt Roper (9):
> >   drm/i915: Disable primary plane if we fail to reconstruct BIOS fb
> >   drm/i915: Dump in-flight plane state while dumping in-flight CRTC
> > state
> >   drm/i915: Clarify plane state during CRTC state dumps (v2)
> >   drm/i915: Dump pipe config after initial FB is reconstructed
> >   drm/i915: Setup clipped src/dest coordinates during FB reconstruction
> > (v2)
> >   drm/i915: Convert hsw_compute_linetime_wm to use in-flight state
> >   drm/i915: Add extra paranoia to ILK watermark calculations
> >   drm/i915: Sanitize watermarks after hardware state readout (v2)
> >   drm/i915: Add two-stage ILK-style watermark programming (v7)
> > 
> >  drivers/gpu/drm/drm_atomic_helper.c  |   1 +
> >  drivers/gpu/drm/i915/i915_drv.h  |   5 +
> >  drivers/gpu/drm/i915/intel_atomic.c  |   1 +
> >  drivers/gpu/drm/i915/intel_display.c | 195 
> > +--
> >  drivers/gpu/drm/i915/intel_drv.h |  31 +-
> >  drivers/gpu/drm/i915/intel_pm.c  | 186 
> > -
> >  6 files changed, 359 insertions(+), 60 deletions(-)
> > 
> > -- 
> > 2.1.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)

[marius . c . vlad]

Second attempt using Imres' hints.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

[Chris Wilson]

On Wed, Nov 25, 2015 at 01:02:20PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> > > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> > > > > From: Akash Goel 
> > > > > 
> > > > > When the object is moved out of CPU read domain, the cachelines
> > > > > are not invalidated immediately. The invalidation is deferred till
> > > > > next time the object is brought back into CPU read domain.
> > > > > But the invalidation is done unconditionally, i.e. even for the case
> > > > > where the cachelines were flushed previously, when the object moved 
> > > > > out
> > > > > of CPU write domain. This is avoidable and would lead to some 
> > > > > optimization.
> > > > > Though this is not a hypothetical case, but is unlikely to occur 
> > > > > often.
> > > > > The aim is to detect changes to the backing storage whilst the
> > > > > data is potentially in the CPU cache, and only clflush in those case.
> > > > > 
> > > > > Signed-off-by: Chris Wilson 
> > > > > Signed-off-by: Akash Goel 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > >  drivers/gpu/drm/i915/i915_gem.c | 9 -
> > > > >  2 files changed, 9 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index df9316f..fedb71d 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> > > > >   unsigned long gt_ro:1;
> > > > >   unsigned int cache_level:3;
> > > > >   unsigned int cache_dirty:1;
> > > > > + unsigned int cache_clean:1;
> > > > 
> > > > So now we have cache_dirty and cache_clean which seems redundant,
> > > > except somehow cache_dirty != !cache_clean?
> > 
> > Exactly, not entirely redundant. I did think something along MESI lines
> > would be useful, but that didn't capture the different meanings we
> > employ.
> > 
> > cache_dirty tracks whether we have been eliding the clflush.
> > 
> > cache_clean tracks whether we know the cache has been completely
> > clflushed.
> 
> Can we know that with speculative prefetching and whatnot?

"The memory attribute of the page containing the affected line has no
effect on the behavior of this instruction. It should be noted that
processors are free to speculative fetch and cache data from system
memory regions assigned a memory-type allowing for speculative reads
(i.e. WB, WC, WT memory types). The Streaming SIMD Extensions PREFETCHh
instruction is considered a hint to this speculative behavior. Because
this speculative fetching can occur at any time and is not tied to
instruction execution, CLFLUSH is not ordered with respect to PREFETCHh
or any of the speculative fetching mechanisms (that is, data could be
speculative loaded into the cache just before, during, or after the
execution of a CLFLUSH to that cache line)."

which taken to the extreme means that we can't get away with this trick.

If we can at least guarantee that such speculation can't extend beyond
a page boundary that will be enough to assert that the patch is valid.

Hopefully someone knows a CPU guru or two.
-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 0/9] Wrap up ILK-style atomic watermarks

[Ville Syrjälä]

On Wed, Nov 25, 2015 at 09:04:11AM -0800, Matt Roper wrote:
> On Wed, Nov 25, 2015 at 07:00:11PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 25, 2015 at 08:48:26AM -0800, Matt Roper wrote:
> > > We've been chasing a regression[1] that prevented us from merging the last
> > > couple patches of the ILK-style atomic watermark series.  We've finally
> > > identified the culprit --- if we fail to reconstruct the BIOS FB, our 
> > > internal
> > > driver state was left in an inconsistent state which caused confusion for 
> > > the
> > > watermark code.  Here's a series that collects that fix (along with a 
> > > couple
> > > other bugfixes that were found while debugging), a few debugging 
> > > enhancements,
> > > and the completion of the ILK atomic watermark series.
> > > 
> > >  * The first patch in this series addresses that issue and
> > >ensures that we cleanly turn off the primary plane if we're unable to 
> > > inherit
> > >the framebuffer.  
> > >  * Patches 2-4 just clarify/expand some of the information dumped by the
> > >driver while debugging.
> > >  * Patches 5 and 6 fix two additional bugs that were discovered while
> > >searching for the cause of the regression.
> > >  * Patch 7 just adds some extra paranoia and invariant checking to the
> > >watermark code.
> > >  * Patches 8 and 9 are the two final patches from the original atomic 
> > > watermark
> > >series; with the fixes earlier in the series, we've confirmed that 
> > > they no
> > >longer cause regressions on Jani's machine.
> > > 
> > > [1] 
> > > http://lists.freedesktop.org/archives/intel-gfx/2015-October/077113.html
> > 
> > Quickly skimmed through the series to see if there was a fix to
> > the "merging optimal wms instead of merging active wms like we
> > should" bug we have in the current code right now. Nothing
> > relevant caught my eye at least.
> 
> I'm not sure I'm aware of this problem; is there a bugzilla or mailing
> list thread that describes the issue?

Maybe not. The problem is that ilk_wm_merge() and co. use the optimal
wms when merging from all pipes. They should use the active wms
instead.

> 
> 
> Matt
> 
> > 
> > > 
> > > Matt Roper (9):
> > >   drm/i915: Disable primary plane if we fail to reconstruct BIOS fb
> > >   drm/i915: Dump in-flight plane state while dumping in-flight CRTC
> > > state
> > >   drm/i915: Clarify plane state during CRTC state dumps (v2)
> > >   drm/i915: Dump pipe config after initial FB is reconstructed
> > >   drm/i915: Setup clipped src/dest coordinates during FB reconstruction
> > > (v2)
> > >   drm/i915: Convert hsw_compute_linetime_wm to use in-flight state
> > >   drm/i915: Add extra paranoia to ILK watermark calculations
> > >   drm/i915: Sanitize watermarks after hardware state readout (v2)
> > >   drm/i915: Add two-stage ILK-style watermark programming (v7)
> > > 
> > >  drivers/gpu/drm/drm_atomic_helper.c  |   1 +
> > >  drivers/gpu/drm/i915/i915_drv.h  |   5 +
> > >  drivers/gpu/drm/i915/intel_atomic.c  |   1 +
> > >  drivers/gpu/drm/i915/intel_display.c | 195 
> > > +--
> > >  drivers/gpu/drm/i915/intel_drv.h |  31 +-
> > >  drivers/gpu/drm/i915/intel_pm.c  | 186 
> > > -
> > >  6 files changed, 359 insertions(+), 60 deletions(-)
> > > 
> > > -- 
> > > 2.1.4
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795

-- 
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] tests/gem_eio: Disable reset for wait subtests

[Chris Wilson]

On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote:
> This testcase tries to validate -EIO behaviour by disabling gpu reset
> support in the kernel. Except that the wait subtest forgot to do that,
> and therefore gets a return value of 0 instead of the expected -EIO.
> 

Wrong. It was intentionally not using reset=false.
-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 5/9] drm/i915: Setup clipped src/dest coordinates during FB reconstruction (v2)

[Matt Roper]

Plane state objects contain two copies of src/dest coordinates:  the
original (requested by userspace) coordinates in the base
drm_plane_state object, and a second, clipped copy (i.e., what we
actually want to program to the hardware) in intel_plane_state.  We've
only been setting up the former set of values during boot time FB
reconstruction, but we should really be initializing both.

Note that the code here probably still needs some more work since we
make a lot of assumptions about how the BIOS programmed the hardware
that may not always be true, especially on gen9+; e.g.,
 * Primary plane might not be positioned at 0,0
 * Primary plane could have been rotated by the BIOS
 * Primary plane might be scaled
 * The BIOS fb might be a single "extended mode" FB that spans
   multiple displays.
 * ...etc...

v2: Reword/expand commit message description of assumptions we make

Signed-off-by: Matt Roper 
Reviewed-by(v1): Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 73e9bf9..00e4c37 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2599,6 +2599,8 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
struct drm_plane_state *plane_state = primary->state;
struct drm_crtc_state *crtc_state = intel_crtc->base.state;
struct intel_plane *intel_plane = to_intel_plane(primary);
+   struct intel_plane_state *intel_state =
+   to_intel_plane_state(plane_state);
struct drm_framebuffer *fb;
 
if (!plane_config->fb)
@@ -2659,6 +2661,15 @@ valid_fb:
plane_state->crtc_w = fb->width;
plane_state->crtc_h = fb->height;
 
+   intel_state->src.x1 = plane_state->src_x;
+   intel_state->src.y1 = plane_state->src_y;
+   intel_state->src.x2 = plane_state->src_x + plane_state->src_w;
+   intel_state->src.y2 = plane_state->src_y + plane_state->src_h;
+   intel_state->dst.x1 = plane_state->crtc_x;
+   intel_state->dst.y1 = plane_state->crtc_y;
+   intel_state->dst.x2 = plane_state->crtc_x + plane_state->crtc_w;
+   intel_state->dst.y2 = plane_state->crtc_y + plane_state->crtc_h;
+
obj = intel_fb_obj(fb);
if (obj->tiling_mode != I915_TILING_NONE)
dev_priv->preserve_bios_swizzle = true;
-- 
2.1.4

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

[Intel-gfx] [PATCH 2/9] drm/i915: Dump in-flight plane state while dumping in-flight CRTC state

[Matt Roper]

The intel_dump_pipe_config() always dumps the currently active plane
state for each plane on a CRTC.  If we're calling this function to dump
CRTC state that is in-flight (not yet active), then this mismatch can be
misleading and confusing.  Let's pay attention to whether the state
we're dumping is part of an in-flight transaction (because
crtc_state->state is non-NULL); if it is, we'll dump the corresponding
in-flight plane state instead of the active state.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d03a235..0e74287 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12162,11 +12162,23 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
 
DRM_DEBUG_KMS("planes on this crtc\n");
list_for_each_entry(plane, >mode_config.plane_list, head) {
+   struct drm_plane_state *ps = NULL;
+
intel_plane = to_intel_plane(plane);
if (intel_plane->pipe != crtc->pipe)
continue;
 
-   state = to_intel_plane_state(plane->state);
+   /* Get in-flight plane state, if any */
+   if (pipe_config->base.state)
+   ps = 
drm_atomic_get_existing_plane_state(pipe_config->base.state,
+plane);
+
+   /* If no in-flight state, use active state instead */
+   if (!ps)
+   ps = plane->state;
+
+   state = to_intel_plane_state(ps);
+
fb = state->base.fb;
if (!fb) {
DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d "
-- 
2.1.4

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

[Intel-gfx] [PATCH 6/9] drm/i915: Convert hsw_compute_linetime_wm to use in-flight state

[Matt Roper]

When watermark calculation was moved up to the atomic check phase, the
code was updated to calculate based on in-flight atomic state rather
than already-committed state.  However the hsw_compute_linetime_wm()
didn't get updated and continued to pull values out of the
currently-committed CRTC state.  On platforms that call this function
(HSW/BDW only), this will cause problems when we go to enable the CRTC
since we'll pull the current mode (off) rather than the mode we're
calculating for and wind up with a divide by zero error.

This was an oversight in commit:

commit a28170f3389f4e42db95e595b0d86384a79de696
Author: Matt Roper 
Date:   Thu Sep 24 15:53:16 2015 -0700

drm/i915: Calculate ILK-style watermarks during atomic check (v3)

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 96f45d7..6efb908 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1990,14 +1990,19 @@ static void ilk_compute_wm_level(const struct 
drm_i915_private *dev_priv,
 }
 
 static uint32_t
-hsw_compute_linetime_wm(struct drm_device *dev, struct drm_crtc *crtc)
+hsw_compute_linetime_wm(struct drm_device *dev,
+   struct intel_crtc_state *cstate)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   const struct drm_display_mode *adjusted_mode = 
_crtc->config->base.adjusted_mode;
+   const struct drm_display_mode *adjusted_mode =
+   >base.adjusted_mode;
u32 linetime, ips_linetime;
 
-   if (!intel_crtc->active)
+   if (!cstate->base.active)
+   return 0;
+   if (WARN_ON(adjusted_mode->crtc_clock == 0))
+   return 0;
+   if (WARN_ON(dev_priv->cdclk_freq == 0))
return 0;
 
/* The WM are computed with base on how long it takes to fill a single
@@ -2305,8 +2310,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc 
*intel_crtc,
 pristate, sprstate, curstate, _wm->wm[0]);
 
if (IS_HASWELL(dev) || IS_BROADWELL(dev))
-   pipe_wm->linetime = hsw_compute_linetime_wm(dev,
-   _crtc->base);
+   pipe_wm->linetime = hsw_compute_linetime_wm(dev, cstate);
 
/* LP0 watermarks always use 1/2 DDB partitioning */
ilk_compute_wm_maximums(dev, 0, , INTEL_DDB_PART_1_2, );
-- 
2.1.4

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

[Intel-gfx] [PATCH 4/9] drm/i915: Dump pipe config after initial FB is reconstructed

[Matt Roper]

We dump during HW state readout, but that's too early to reflect how the
primary plane is actually configured.

In the future it would be nice if we could just read out HW state and
reconstruct FB's at the same point, but at the moment we don't have GEM
initialized sufficiently during hardware readout.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e5c522b..73e9bf9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15228,6 +15228,9 @@ void intel_modeset_init(struct drm_device *dev)
 * just get the first one.
 */
intel_find_initial_plane_obj(crtc, _config);
+
+   intel_dump_pipe_config(crtc, crtc->config,
+  "[state after init fb reconstruction]");
}
 }
 
-- 
2.1.4

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

[Intel-gfx] [PATCH 9/9] drm/i915: Add two-stage ILK-style watermark programming (v7)

[Matt Roper]

In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time.  These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means they can be programmed immediately when we commit the
atomic state (without waiting for a vblank).  Once the vblank does
happen, we can then re-program watermarks to the more optimal final
value.

v2: Significant rebasing/rewriting.

v3:
 - Move 'need_postvbl_update' flag to CRTC state (Daniel)
 - Don't forget to check intermediate watermark values for validity
   (Maarten)
 - Don't due async watermark optimization; just do it at the end of the
   atomic transaction, after waiting for vblanks.  We do want it to be
   async eventually, but adding that now will cause more trouble for
   Maarten's in-progress work.  (Maarten)
 - Don't allocate space in crtc_state for intermediate watermarks on
   platforms that don't need it (gen9+).
 - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
   now that ilk_update_wm is gone.

v4:
 - Add a wm_mutex to cover updates to intel_crtc->active and the
   need_postvbl_update flag.  Since we don't have async yet it isn't
   terribly important yet, but might as well add it now.
 - Change interface to program watermarks.  Platforms will now expose
   .initial_watermarks() and .optimize_watermarks() functions to do
   watermark programming.  These should lock wm_mutex, copy the
   appropriate state values into intel_crtc->active, and then call
   the internal program watermarks function.

v5:
 - Skip intermediate watermark calculation/check during initial hardware
   readout since we don't trust the existing HW values (and don't have
   valid values of our own yet).
 - Don't try to call .optimize_watermarks() on platforms that don't have
   atomic watermarks yet.  (Maarten)

v6:
 - Rebase

v7:
 - Further rebase

Signed-off-by: Matt Roper 
Reviewed-by(v5): Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h  |   6 +-
 drivers/gpu/drm/i915/intel_atomic.c  |   1 +
 drivers/gpu/drm/i915/intel_display.c |  90 +++-
 drivers/gpu/drm/i915/intel_drv.h |  31 ++-
 drivers/gpu/drm/i915/intel_pm.c  | 160 ---
 5 files changed, 232 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5172604..427b488 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -630,7 +630,11 @@ struct drm_i915_display_funcs {
  struct dpll *best_clock);
int (*compute_pipe_wm)(struct intel_crtc *crtc,
   struct drm_atomic_state *state);
-   void (*program_watermarks)(struct intel_crtc_state *cstate);
+   int (*compute_intermediate_wm)(struct drm_device *dev,
+  struct intel_crtc *intel_crtc,
+  struct intel_crtc_state *newstate);
+   void (*initial_watermarks)(struct intel_crtc_state *cstate);
+   void (*optimize_watermarks)(struct intel_crtc_state *cstate);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void (*modeset_commit_cdclk)(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 643f342..b91e166 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -95,6 +95,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
 
crtc_state->update_pipe = false;
crtc_state->disable_lp_wm = false;
+   crtc_state->wm.need_postvbl_update = false;
 
return _state->base;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index eb52afa..8db0486 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11801,6 +11801,12 @@ int intel_plane_atomic_calc_changes(struct 
drm_crtc_state *crtc_state,
intel_crtc->atomic.update_wm_pre = true;
}
 
+   /* Pre-gen9 platforms need two-step watermark updates */
+   if ((intel_crtc->atomic.update_wm_pre || 
intel_crtc->atomic.update_wm_post) &&
+   INTEL_INFO(dev)->gen < 9 &&
+   dev_priv->display.optimize_watermarks)
+   to_intel_crtc_state(crtc_state)->wm.need_postvbl_update = true;
+
if (visible || was_visible)
intel_crtc->atomic.fb_bits |=
to_intel_plane(plane)->frontbuffer_bit;
@@ -11957,8 +11963,29 @@ static int intel_crtc_atomic_check(struct drm_crtc 
*crtc,
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(intel_crtc, state);
-

[Intel-gfx] [PATCH 3/9] drm/i915: Clarify plane state during CRTC state dumps (v2)

[Matt Roper]

During state dumping, list planes that have an FB but are invisible
(e.g., because they're offscreen or clipped by other planes) as "not
visible" rather than "enabled."  While we're at it, dump the FB format
as a human-readable string rather than a hex format code.

v2: Don't add bpp; make format human-readable instead. (Ville)

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 0e74287..e5c522b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12190,13 +12190,15 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
continue;
}
 
-   DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d enabled",
+   DRM_DEBUG_KMS("%s PLANE:%d plane: %u.%u idx: %d %s",
plane->type == DRM_PLANE_TYPE_CURSOR ? "CURSOR" : 
"STANDARD",
plane->base.id, intel_plane->pipe,
crtc->base.primary == plane ? 0 : intel_plane->plane + 
1,
-   drm_plane_index(plane));
-   DRM_DEBUG_KMS("\tFB:%d, fb = %ux%u format = 0x%x",
-   fb->base.id, fb->width, fb->height, fb->pixel_format);
+   drm_plane_index(plane),
+   state->visible ? "enabled" : "not visible");
+   DRM_DEBUG_KMS("\tFB:%d, fb = %ux%u format = %s",
+   fb->base.id, fb->width, fb->height,
+   drm_get_format_name(fb->pixel_format));
DRM_DEBUG_KMS("\tscaler:%d src (%u, %u) %ux%u dst (%u, %u) 
%ux%u\n",
state->scaler_id,
state->src.x1 >> 16, state->src.y1 >> 16,
-- 
2.1.4

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

[Intel-gfx] [PATCH 1/9] drm/i915: Disable primary plane if we fail to reconstruct BIOS fb

[Matt Roper]

If we fail to reconstruct the BIOS fb (e.g., because the FB is too
large), we'll be left with plane state that indicates the primary plane
is visible yet has a NULL fb.  This mismatch causes problems later on
(e.g., for the watermark code).  Since we've failed to reconstruct the
BIOS FB, the best solution is to just disable the primary plane and
pretend the BIOS never had it enabled.

Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Signed-off-by: Matt Roper 
---
With this patch, the rest of this series now runs without problems on Jani's
system where the regressions were originally reported.

Chris pointed out that this might also fix some of the other bugzillas we have
on older platforms where there's a GPU hang on failed FB takeover.  I don't
think I have any platforms that can reproduce those types of problems to
verify, but he listed candidate bugs as:

https://bugs.freedesktop.org/show_bug.cgi?id=89319
https://bugs.freedesktop.org/show_bug.cgi?id=87677
https://bugs.freedesktop.org/show_bug.cgi?id=89146
https://bugs.freedesktop.org/show_bug.cgi?id=91653

 drivers/gpu/drm/i915/intel_display.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4b21d5e..d03a235 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2597,6 +2597,8 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
struct drm_i915_gem_object *obj;
struct drm_plane *primary = intel_crtc->base.primary;
struct drm_plane_state *plane_state = primary->state;
+   struct drm_crtc_state *crtc_state = intel_crtc->base.state;
+   struct intel_plane *intel_plane = to_intel_plane(primary);
struct drm_framebuffer *fb;
 
if (!plane_config->fb)
@@ -2633,6 +2635,17 @@ intel_find_initial_plane_obj(struct intel_crtc 
*intel_crtc,
}
}
 
+   /*
+* We've failed to reconstruct the BIOS FB.  Current display state
+* indicates that the primary plane is visible, but has a NULL FB,
+* which will lead to problems later if we don't fix it up.  The
+* simplest solution is to just disable the primary plane now and
+* pretend the BIOS never had it enabled.
+*/
+   to_intel_plane_state(plane_state)->visible = false;
+   crtc_state->plane_mask &= ~(1 << drm_plane_index(primary));
+   intel_plane->disable_plane(primary, _crtc->base);
+
return;
 
 valid_fb:
-- 
2.1.4

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

[Intel-gfx] [PATCH i-g-t] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)

[marius . c . vlad]

From: Marius Vlad 

Signed-off-by: Marius Vlad 
---
 tests/pm_rpm.c | 120 +
 1 file changed, 120 insertions(+)

diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index c4fb19c..157cf29 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -1729,6 +1729,120 @@ static void planes_subtest(bool universal, bool dpms)
}
 }
 
+static void pm_test_tiling(void)
+{
+   uint32_t *handles;
+   uint8_t **gem_bufs;
+
+   int max_gem_objs = 0;
+   uint8_t off_bit = 20;
+   uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
+
+   uint32_t i, j, tiling_modes[3] = {
+   I915_TILING_NONE,
+   I915_TILING_X,
+   I915_TILING_Y,
+   };
+   uint32_t ti, sw;
+
+   /* default value */
+   uint32_t stride = 1024;
+
+   /* calculate how many objects we can map */
+   for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
+   ;
+
+   gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
+   handles = malloc(sizeof(uint32_t) * max_gem_objs);
+
+   /* map to gtt and store some random data */
+   for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+   handles[i] = gem_create(drm_fd, j);
+   gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
+   memset(gem_bufs[i], 0x65, j);
+   }
+
+   /* try to set different tiling for each handle */
+   for (i = 0; i < ARRAY_SIZE(tiling_modes); i++) {
+   disable_all_screens_and_wait(_data);
+
+   for (j = 0; j < max_gem_objs; j++) {
+   gem_set_tiling(drm_fd, handles[j], tiling_modes[i], 
stride);
+
+   gem_get_tiling(drm_fd, handles[j], , );
+   igt_assert(tiling_modes[i] == ti);
+   }
+
+   enable_one_screen_and_wait(_data);
+   }
+
+   for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+   igt_assert(munmap(gem_bufs[i], j) == 0);
+   gem_close(drm_fd, handles[i]);
+   }
+
+   free(gem_bufs);
+   free(handles);
+}
+
+static void pm_test_caching(void)
+{
+   uint32_t *handles;
+   uint8_t **gem_bufs;
+   int8_t has_caching_display = -1;
+
+   uint32_t i, j, got_caching;
+   uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
+   uint32_t cache_levels[3] = {
+   I915_CACHING_NONE,
+   I915_CACHING_CACHED,/* LLC caching */
+   I915_CACHING_DISPLAY,   /* eDRAM caching */
+   };
+
+   int max_gem_objs = 0;
+   uint8_t off_bit = 20;
+
+   for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
+   ;
+
+   gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
+   handles = malloc(sizeof(uint32_t) * max_gem_objs);
+
+   for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+   handles[i] = gem_create(drm_fd, j);
+   gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
+   memset(gem_bufs[i], 0x65, j);
+   }
+
+   /* figure out if we have cache display available on the platform */
+   gem_set_caching(drm_fd, handles[0], I915_CACHING_DISPLAY);
+   if (gem_get_caching(drm_fd, handles[0]))
+   has_caching_display++;
+
+   for (i = 0; i < ARRAY_SIZE(cache_levels) + has_caching_display; i++) {
+   disable_all_screens_and_wait(_data);
+
+   for (j = 0; j < max_gem_objs; j++) {
+   gem_set_caching(drm_fd, handles[j], cache_levels[i]);
+
+   igt_debug("Verying cache for handle %u, level %u\n", j, 
i);
+   got_caching = gem_get_caching(drm_fd, handles[j]);
+
+   igt_assert(got_caching == cache_levels[i]);
+   }
+
+   enable_one_screen_and_wait(_data);
+   }
+
+   for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+   igt_assert(munmap(gem_bufs[i], j) == 0);
+   gem_close(drm_fd, handles[i]);
+   }
+
+   free(handles);
+   free(gem_bufs);
+}
+
 static void fences_subtest(bool dpms)
 {
int i;
@@ -1927,6 +2041,12 @@ int main(int argc, char *argv[])
igt_subtest("gem-execbuf-stress-extra-wait")
gem_execbuf_stress_subtest(rounds, WAIT_STATUS | WAIT_EXTRA);
 
+   /* power-wake reference tests */
+   igt_subtest("pm-tiling")
+   pm_test_tiling();
+   igt_subtest("pm-caching")
+   pm_test_caching();
+
igt_fixture
teardown_environment();
 
-- 
2.6.2

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

[Intel-gfx] [PATCH 3/9] drm/nouveau: Use EAGAIN instead EBUSY for aux retry.

[Rodrigo Vivi]

Current EBUSY meaning is immediately retry, but this is
about to change. DRM aux transfer is about to change and
make EAGAIN the immediately retry and use EBUSY to wait
a bit for aux channels to recover for any error or wake up.

This has no functional change if the EAGAIN support is in
place already for drm aux transfer.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c   | 4 ++--
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c
index 954f5b7..a6cd729 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c
@@ -52,7 +52,7 @@ g94_i2c_aux_init(struct g94_i2c_aux *aux)
udelay(1);
if (!timeout--) {
AUX_ERR(>base, "begin idle timeout %08x", ctrl);
-   return -EBUSY;
+   return -EAGAIN;
}
} while (ctrl & 0x0301);
 
@@ -65,7 +65,7 @@ g94_i2c_aux_init(struct g94_i2c_aux *aux)
if (!timeout--) {
AUX_ERR(>base, "magic wait %08x", ctrl);
g94_i2c_aux_fini(aux);
-   return -EBUSY;
+   return -EAGAIN;
}
} while ((ctrl & 0x0300) != urep);
 
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
index bed231b..6814e5b 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c
@@ -52,7 +52,7 @@ gm204_i2c_aux_init(struct gm204_i2c_aux *aux)
udelay(1);
if (!timeout--) {
AUX_ERR(>base, "begin idle timeout %08x", ctrl);
-   return -EBUSY;
+   return -EAGAIN;
}
} while (ctrl & 0x0301);
 
@@ -65,7 +65,7 @@ gm204_i2c_aux_init(struct gm204_i2c_aux *aux)
if (!timeout--) {
AUX_ERR(>base, "magic wait %08x", ctrl);
gm204_i2c_aux_fini(aux);
-   return -EBUSY;
+   return -EAGAIN;
}
} while ((ctrl & 0x0300) != urep);
 
-- 
2.4.3

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

[Intel-gfx] [PATCH 2/9] drm: Introduce EAGAIN handling for immediatelly aux retries

[Rodrigo Vivi]

The goal here is to offload aux retries handling from the
drivers to drm.

However there are 2 differents cases for retry:
1. Immediately retry - Hardware already took care of needed timeouts
   before answering that a retry is possible.
2. Busy - Wait some time and retry.

This driver introduce the support for EAGAIN that can handle the
first case and a following patch will introduce EBUSY waits,
after all drivers counting on immediately retries are changed.

v2: Rebased on top of drm_dp_helper docbook changes.
Also this version add EAGAIN documentation and as suggested by
Jani it inserts a comment at drm_dp_i2c_do_msg explaining EAGAIN
timeout is already handled at i2c level.

Cc: Jani Nikula 
Cc: Dave Airlie 
Signed-off-by: Rodrigo Vivi 
Tested-by: Daniel Stone 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_dp_helper.c | 10 ++
 include/drm/drm_dp_helper.h |  4 
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 9535c5b..2e26097 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -198,6 +198,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
err = aux->transfer(aux, );
mutex_unlock(>hw_mutex);
if (err < 0) {
+   /* Immediately retry */
+   if (err == -EAGAIN)
+   continue;
+
+   /* FIXME: On BUSY we could wait before retrying */
if (err == -EBUSY)
continue;
 
@@ -547,6 +552,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)
ret = aux->transfer(aux, msg);
mutex_unlock(>hw_mutex);
if (ret < 0) {
+
+   /*
+* -EAGAIN retries are handled by i2c layer with
+* timeouts for repeated -EAGAINs
+*/
if (ret == -EBUSY)
continue;
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ed7dbdc..518fc1b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -758,6 +758,10 @@ struct drm_dp_aux {
 *   to check for failure.
 * - -EBUSY: When BUSY helpers will attempt retries before propagating
 *   this error.
+* - -EAGAIN: DPCD helper will attempt immediatelly retries before
+*   propagating this error. i2c helper will only propagate directly
+*   since i2c layer already perform retries with timeouts for repeated
+*   -EAGAINs.
 *
 * Note that the aux helper code assumes that the .transfer() function
 * only modifies the reply field of the drm_dp_aux_msg structure.  The
-- 
2.4.3

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

[Intel-gfx] [PATCH 8/9] drm/i915: Move dummy aux read from read_wake to aux_transfer.

[Rodrigo Vivi]

The goal is to kill the intel_dp_dpcd_read_wake for all, however
Jani noticed we cannot ignore the case introduced by:
'commit f6a1906 ("drm/i915: Do a dummy DPCD read before the actual read")'

So, instead for removing this for now let's apply that dummy read
to all DP_AUX_NATIVE_READ cases. Pratically no functional changes with
this change, but ideally we want to remove this code for here.

Unfortunately I don't have the monitor/hardware that made us
to include this extra call so for now let's move this here and
add a FIXME tag so this case can be properly fixed/verified later.

An alternative plan is to remove completely this piece of code and when
we start getting the corner cases again we investigate it properly to
see if instead of this extra read we can simply handle properly or
return a -EBUSY or -EAGAIN so drm can retry instead.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a02bfa1..0febf8d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -937,7 +937,7 @@ static ssize_t
 intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
 {
struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
-   uint8_t txbuf[20], rxbuf[20];
+   uint8_t txbuf[20], rxbuf[20], dumbuf[20];
size_t txsize, rxsize;
int ret;
 
@@ -974,6 +974,18 @@ intel_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
break;
 
case DP_AUX_NATIVE_READ:
+   /*
+* FIXME: Sometime we just get the same incorrect byte repeated
+* over the entire buffer. Doing just one throw away read
+* initially seems to "solve" it.
+*/
+   dumbuf[0] = (DP_AUX_NATIVE_READ << 4) |
+   ((DP_DPCD_REV >> 16) & 0xf);
+   dumbuf[1] = (DP_DPCD_REV >> 8) & 0xff;
+   dumbuf[2] = DP_DPCD_REV & 0xff;
+   dumbuf[3] = 0;
+   intel_dp_aux_ch(intel_dp, dumbuf, HEADER_SIZE, rxbuf, 2);
+
case DP_AUX_I2C_READ:
txsize = msg->size ? HEADER_SIZE : BARE_ADDRESS_SIZE;
rxsize = msg->size + 1;
@@ -3171,13 +3183,6 @@ intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned 
int offset,
ssize_t ret;
int i;
 
-   /*
-* Sometime we just get the same incorrect byte repeated
-* over the entire buffer. Doing just one throw away read
-* initially seems to "solve" it.
-*/
-   drm_dp_dpcd_read(aux, DP_DPCD_REV, buffer, 1);
-
for (i = 0; i < 3; i++) {
ret = drm_dp_dpcd_read(aux, offset, buffer, size);
if (ret == size)
-- 
2.4.3

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

[Intel-gfx] [PATCH 7/9] drm/i915: Fix random aux transactions failures.

[Rodrigo Vivi]

Mainly aux communications on sink_crc
were failing a lot randomly on recent platforms.
The first solution was to try to use intel_dp_dpcd_read_wake, but then
it was suggested to move retries to drm level.

Since drm level was already taking care of retries and didn't want
to through random retries on that level the second solution was to
put the retries at aux_transfer layer what was nacked.

So I realized we had so many retries in different places and
started to organize that a bit. During this organization I noticed
that we weren't handing at all the case were the message size was
zeroed. And this was exactly the case that was affecting sink_crc.

Also we weren't respect BSPec who says this size message = 0 or > 20
are forbidden.

It is a fact that we still have no clue why we are getting this
forbidden value there. But anyway we need to handle that for now
so we return -EBUSY and drm level takes care of the retries that
are already in place.

v2: Print debug messsage when this case is reached as suggested
by Jani.

Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Rodrigo Vivi 
Tested-by: Daniel Stone  # SKL
---
 drivers/gpu/drm/i915/intel_dp.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 54e85f5..a02bfa1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -899,6 +899,19 @@ done:
/* Unload any bytes sent back from the other side */
recv_bytes = ((status & DP_AUX_CH_CTL_MESSAGE_SIZE_MASK) >>
  DP_AUX_CH_CTL_MESSAGE_SIZE_SHIFT);
+
+   /*
+* By BSpec: "Message sizes of 0 or >20 are not allowed."
+* We have no idea of what happened so we return -EBUSY so
+* drm layer takes care for the necessary retries.
+*/
+   if (recv_bytes == 0 || recv_bytes > 20) {
+   DRM_DEBUG_KMS("Forbidden recv_bytes = %d on aux transaction\n",
+ recv_bytes);
+   ret = -EBUSY;
+   goto out;
+   }
+
if (recv_bytes > recv_size)
recv_bytes = recv_size;
 
-- 
2.4.3

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

[Intel-gfx] [PATCH 0/9] Organize aux retries v3

[Rodrigo Vivi]

This new version first convert the drm_dp_aux doc to new per-member comment 
layout
and introduce a propper documentation for EBUSY/EAGAIN retry cases, as 
requested by
Daniel.

Also accept many suggestions from Jani, but mostly removes the Nacked patch and
introduce a new one to handle the missed case when killing 
intel_dp_dpcd_read_wake.
Ideally I believe we could and should kill that retry, but it needs to be done
in a separated patch and ideally by someone that can reproduce the old issue.

But with this series at least we have some consistency in the code and almost
all retries stay organized at drm level.

But by far the most important patch in this series for myself is
commit ("drm/i915: Fix random aux transactions failures.") who solves
the issues that I face on PSR validation on Skylake platforms.
So if the rest of the series still needs to be discussed, reworked or anything
else, please consider at least merging this patch at least that by itself
already solves my main issue.

Thank you all for all reviews, comments and test so far.

Rodrigo Vivi (9):
  drm: Improve drm_dp_aux DocBook.
  drm: Introduce EAGAIN handling for immediatelly aux retries
  drm/nouveau: Use EAGAIN instead EBUSY for aux retry.
  drm/i915: Use EAGAIN instead EBUSY for aux retry.
  drm: Wait 1ms before retrying aux transactions on EBUSY.
  drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.
  drm/i915: Fix random aux transactions failures.
  drm/i915: Move dummy aux read from read_wake to aux_transfer.
  drm/i915: Kill intel_dp_dpcd_read_wake

 drivers/gpu/drm/drm_dp_helper.c|  18 ++-
 drivers/gpu/drm/i915/intel_dp.c| 141 +
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxg94.c   |   4 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c |   4 +-
 include/drm/drm_dp_helper.h|  69 ++
 5 files changed, 126 insertions(+), 110 deletions(-)

-- 
2.4.3

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

[Intel-gfx] [PATCH 6/9] drm/i915: Avoid EBUSY retry on intel_dp_aux_ch.

[Rodrigo Vivi]

EBUSY retries are already in place at drm level.
We don't need to replicate the job here.

v2: rebase on top of EAGAIN x EBUSY retries change at drm.
EBUSY retry at DRM is now handling the msleep(1).

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 22 +++---
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1261d26..54e85f5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -817,25 +817,9 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 
intel_dp_check_edp(intel_dp);
 
-   /* Try to wait for any previous AUX channel activity */
-   for (try = 0; try < 3; try++) {
-   status = I915_READ_NOTRACE(ch_ctl);
-   if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0)
-   break;
-   msleep(1);
-   }
-
-   if (try == 3) {
-   static u32 last_status = -1;
-   const u32 status = I915_READ(ch_ctl);
-
-   if (status != last_status) {
-   WARN(1, "dp_aux_ch not started status 0x%08x\n",
-status);
-   last_status = status;
-   }
-
-   ret = -EAGAIN;
+   status = I915_READ_NOTRACE(ch_ctl);
+   if ((status & DP_AUX_CH_CTL_SEND_BUSY) != 0) {
+   ret = -EBUSY;
goto out;
}
 
-- 
2.4.3

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

[Intel-gfx] [PATCH 4/9] drm/i915: Use EAGAIN instead EBUSY for aux retry.

[Rodrigo Vivi]

Current EBUSY meaning is immediately retry, but this is
about to change. DRM aux transfer is about to change and
make EAGAIN the immediately retry and use EBUSY to wait
a bit for aux channels to recover for any error or wake up.

This has no functional change if the EAGAIN support is in
place already for drm aux transfer.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2805f0d..1261d26 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -835,7 +835,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
last_status = status;
}
 
-   ret = -EBUSY;
+   ret = -EAGAIN;
goto out;
}
 
@@ -890,7 +890,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
 
if ((status & DP_AUX_CH_CTL_DONE) == 0) {
DRM_ERROR("dp_aux_ch not done status 0x%08x\n", status);
-   ret = -EBUSY;
+   ret = -EAGAIN;
goto out;
}
 
-- 
2.4.3

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

[Intel-gfx] [PATCH 1/9] drm: Improve drm_dp_aux DocBook.

[Rodrigo Vivi]

This patch converts drm_dp_aux doc to new per-member comment layout
that 4.4 supports as suggested by Daniel.

But also:

1. to let the split text with sense this patch also
introduce a brief general AUX channel definition.

2. Remove .name and .dev duplications from the original text.

3. Improve .transfer() error code handler making more clear
   what is going on with each error code generated or handled

Cc: Daniel Vetter 
Signed-off-by: Rodrigo Vivi 
---
 include/drm/drm_dp_helper.h | 64 +
 1 file changed, 42 insertions(+), 22 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 1252108..ed7dbdc 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -703,26 +703,9 @@ struct drm_dp_aux_msg {
 
 /**
  * struct drm_dp_aux - DisplayPort AUX channel
- * @name: user-visible name of this AUX channel and the I2C-over-AUX adapter
- * @ddc: I2C adapter that can be used for I2C-over-AUX communication
- * @dev: pointer to struct device that is the parent for this AUX channel
- * @hw_mutex: internal mutex used for locking transfers
- * @transfer: transfers a message representing a single AUX transaction
  *
- * The .dev field should be set to a pointer to the device that implements
- * the AUX channel.
- *
- * The .name field may be used to specify the name of the I2C adapter. If set 
to
- * NULL, dev_name() of .dev will be used.
- *
- * Drivers provide a hardware-specific implementation of how transactions
- * are executed via the .transfer() function. A pointer to a drm_dp_aux_msg
- * structure describing the transaction is passed into this function. Upon
- * success, the implementation should return the number of payload bytes
- * that were transferred, or a negative error-code on failure. Helpers
- * propagate errors from the .transfer() function, with the exception of
- * the -EBUSY error, which causes a transaction to be retried. On a short,
- * helpers will return -EPROTO to make it simpler to check for failure.
+ * AUX channel is a half duplex channel used to transfer messages between
+ * source an sink. Mainly used for write and read sink DPCD registers.
  *
  * An AUX channel can also be used to transport I2C messages to a sink. A
  * typical application of that is to access an EDID that's present in the
@@ -734,15 +717,52 @@ struct drm_dp_aux_msg {
  * received, the adapter will drop down to the size given by the partial
  * response for this transaction only.
  *
- * Note that the aux helper code assumes that the .transfer() function
- * only modifies the reply field of the drm_dp_aux_msg structure.  The
- * retry logic and i2c helpers assume this is the case.
  */
 struct drm_dp_aux {
+   /**
+* @name: user-visible name of this AUX channel and the I2C-over-AUX
+*adapter. If set to NULL, dev_name() of .dev will be used.
+*/
const char *name;
+
+   /**
+* @ddc: I2C adapter that can be used for I2C-over-AUX communication
+*/
struct i2c_adapter ddc;
+
+   /**
+* @dev: pointer to struct device that is the parent and implements
+*   this AUX channel
+*/
struct device *dev;
+
+   /**
+* @hw_mutex: internal mutex used for locking transfers
+*/
struct mutex hw_mutex;
+
+   /**
+* @transfer: transfers a message representing a single AUX transaction
+*
+* Drivers provide a hardware-specific implementation of how
+* transactions are executed via this function. A pointer to a
+* drm_dp_aux_msg structure describing the transaction is passed into
+* this function.
+*
+* Returns:
+* Upon success, the implementation should return the number of
+* payload bytes that were transferred.
+* Otherwise a negative error-code on failure. Helpers propagate errors
+* from the .transfer() function, with the exception of:
+* - -EPROTO: On a short, helpers will return -EPROTO to make it simpler
+*   to check for failure.
+* - -EBUSY: When BUSY helpers will attempt retries before propagating
+*   this error.
+*
+* Note that the aux helper code assumes that the .transfer() function
+* only modifies the reply field of the drm_dp_aux_msg structure.  The
+* retry logic and i2c helpers assume this is the case.
+*/
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
unsigned i2c_nack_count, i2c_defer_count;
-- 
2.4.3

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

[Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects

[Chris Wilson]

If the system has no available swap pages, we cannot make forward
progress in the shrinker by releasing active pages, only by releasing
purgeable pages which are immediately reaped. Take total_swap_pages into
account when counting up available objects to be shrunk and subsequently
shrinking them. By doing so, we avoid unbinding objects that cannot be
shrunk and so wasting CPU cycles flushing those objects from the GPU to
the system and then immediately back again (as they will more than
likely be reused shortly after).

Based on a patch by Akash Goel.

v2: Check for frontswap without physical swap (or dedicated swap space).
If frontswap is available, we may be able to compress the GPU pages
instead of swapping out to disk. In this case, we do want to shrink GPU
objects and so make them available for compressing.

Reported-by: Akash Goel 
Signed-off-by: Chris Wilson 
Cc: linux...@kvack.org
Cc: Akash Goel 
Cc: sourab.gu...@intel.com
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 61 +++-
 1 file changed, 45 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index f7df54a8ee2b..451a75a056da 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -22,6 +22,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -47,6 +48,46 @@ static bool mutex_is_locked_by(struct mutex *mutex, struct 
task_struct *task)
 #endif
 }
 
+static int num_vma_bound(struct drm_i915_gem_object *obj)
+{
+   struct i915_vma *vma;
+   int count = 0;
+
+   list_for_each_entry(vma, >vma_list, vma_link) {
+   if (drm_mm_node_allocated(>node))
+   count++;
+   if (vma->pin_count)
+   count++;
+   }
+
+   return count;
+}
+
+static bool swap_available(void)
+{
+   return total_swap_pages || frontswap_enabled;
+}
+
+static bool can_release_pages(struct drm_i915_gem_object *obj)
+{
+   /* Only report true if by unbinding the object and putting its pages
+* we can actually make forward progress towards freeing physical
+* pages.
+*
+* If the pages are pinned for any other reason than being bound
+* to the GPU, simply unbinding from the GPU is not going to succeed
+* in release our pin count on the pages themselves.
+*/
+   if (obj->pages_pin_count != num_vma_bound(obj))
+   return false;
+
+   /* We can only return physical pages if we either discard them
+* (because the user has marked them as being purgeable) or if
+* we can move their contents out to swap.
+*/
+   return swap_available() || obj->madv == I915_MADV_DONTNEED;
+}
+
 /**
  * i915_gem_shrink - Shrink buffer object caches
  * @dev_priv: i915 device
@@ -129,6 +170,9 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
if ((flags & I915_SHRINK_ACTIVE) == 0 && obj->active)
continue;
 
+   if (!can_release_pages(obj))
+   continue;
+
drm_gem_object_reference(>base);
 
/* For the unbound phase, this should be a no-op! */
@@ -188,21 +232,6 @@ static bool i915_gem_shrinker_lock(struct drm_device *dev, 
bool *unlock)
return true;
 }
 
-static int num_vma_bound(struct drm_i915_gem_object *obj)
-{
-   struct i915_vma *vma;
-   int count = 0;
-
-   list_for_each_entry(vma, >vma_list, vma_link) {
-   if (drm_mm_node_allocated(>node))
-   count++;
-   if (vma->pin_count)
-   count++;
-   }
-
-   return count;
-}
-
 static unsigned long
 i915_gem_shrinker_count(struct shrinker *shrinker, struct shrink_control *sc)
 {
@@ -222,7 +251,7 @@ i915_gem_shrinker_count(struct shrinker *shrinker, struct 
shrink_control *sc)
count += obj->base.size >> PAGE_SHIFT;
 
list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
-   if (!obj->active && obj->pages_pin_count == num_vma_bound(obj))
+   if (!obj->active && can_release_pages(obj))
count += obj->base.size >> PAGE_SHIFT;
}
 
-- 
2.6.2

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects

[Chris Wilson]

On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> +static bool swap_available(void)
> +{
> + return total_swap_pages || frontswap_enabled;
> +}

Of course these aren't exported symbols, so really this is just RFC
right now.
-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 i-g-t] tests/gem_softpin: New tests for softpin feature

[Vinay Belgaumkar]

These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.

Caveat: These tests were designed to run on 64-bit system. Future work
includes adding logic to ensure these tests can run on 32-bit systems with
PPGTT support. Some tests are currently disabled for 32-bit systems for that
reason.

v2: Added cc and signed-off-by fields

v3: Fixed review comments, added helper functions. Removed userptr error
scenarios covered by existing userptr tests. Modified stress test to have
100K buffers, it now runs for ~30 mins, checks every element has been written
to correctly, and pins buffers at different VMAs.

v4: Changed name to gem_softpin

v5: More fixes. Removed the file based tests, will move them to userptr tests.
Added a function that validates appropriate PPGTT support before running tests.
Optimized stack space and memory footprint in stress test. Removed the eviction
test, will add it back after verifying proper functionality.

Cc: Michel Thierry 
Cc: Tvrtko Ursulin 
Signed-off-by: Vinay Belgaumkar 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/gem_softpin.c| 972 +
 3 files changed, 974 insertions(+)
 create mode 100644 tests/gem_softpin.c

diff --git a/tests/.gitignore b/tests/.gitignore
index 80af9a7..424870b 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -21,6 +21,7 @@ gem_bad_blit
 gem_bad_length
 gem_bad_reloc
 gem_basic
+gem_softpin
 gem_caching
 gem_close_race
 gem_concurrent_all
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 8fb2de8..2008d4a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -11,6 +11,7 @@ TESTS_progs_M = \
drv_hangman \
gem_bad_reloc \
gem_basic \
+   gem_softpin \
gem_caching \
gem_close_race \
gem_concurrent_blit \
diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c
new file mode 100644
index 000..95b664a
--- /dev/null
+++ b/tests/gem_softpin.c
@@ -0,0 +1,972 @@
+/*
+ * Copyright © 2015 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.
+ *
+ * Authors:
+ *Vinay Belgaumkar 
+ *Thomas Daniel 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "drm.h"
+#include "ioctl_wrappers.h"
+#include "drmtest.h"
+#include "intel_chipset.h"
+#include "intel_io.h"
+#include "i915_drm.h"
+#include 
+#include 
+#include 
+#include 
+#include "igt_kms.h"
+#include 
+#include 
+#include 
+
+#define BO_SIZE 4096
+#define MULTIPAGE_BO_SIZE 2 * BO_SIZE
+#define STORE_BATCH_BUFFER_SIZE 4
+#define EXEC_OBJECT_PINNED (1<<4)
+#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
+#define SHARED_BUFFER_SIZE 4096
+#define NUM_EXEC_OBJECTS 2
+
+typedef struct drm_i915_gem_userptr i915_gem_userptr;
+
+static uint32_t init_userptr(int fd, i915_gem_userptr*, void* ptr, 
+   uint64_t size, bool read_only);
+static void *create_mem_buffer(uint64_t size);
+static int gem_call_userptr_ioctl(int fd, i915_gem_userptr *userptr);
+static void gem_basic_test(void);
+static void gem_pin_invalid_vma_test(void);
+static void gem_pin_overlap_test(void);
+static void gem_pin_high_address_test(void);
+
+#define NO_PPGTT 0
+#define ALIASING_PPGTT 1
+#define FULL_32_BIT_PPGTT 2
+#define FULL_48_BIT_PPGTT 3
+/* uses_full_ppgtt
+ * Finds supported PPGTT details. 
+ * @fd DRM fd
+ * @min can be
+ * 0 - No PPGTT
+ * 1 - Aliasing PPGTT
+ * 2 - Full PPGTT (32b)
+ * 3 - Full PPGTT 

[Intel-gfx] [PATCH 9/9] drm/i915: Kill intel_dp_dpcd_read_wake

[Rodrigo Vivi]

This read wake with retries were initially added by 2 commits:

commit 61da5fab ("drm/i915/dp: retry link status read 3 times on failure")
commit 899526d9 ("drm/i915/dp: try to read receiver capabilities 3 times
 when detecting")

Both mentioning section 9.1 of the 1.1a DisplayPort spec, that actually
tell us to retry three times on certain case when
"writing 01h to DPCD address 600h" and this code is already in place in
our driver. Added by:

commit c7ad3810 ("drm/i915/dp: manage sink power state if possible")

At this point we have no visibility if those patches were added to
workaround certain corner cases like lazy dongles or what, but also
at that time there wasn't enough retries on the proper places.

So my proposal is to remove these retries for now that we have drm
handling the retries and if we face any corner case back again we
study it to return EAGAIN or EBUSY to force retries at drm instead
of handling them here.

v2: Improve commit message trying to explain the origin of the retries.

v3: Rebase on top of new commit ("drm/i915: Move dummy aux read from
read_wake to aux_transfer."). Jani noticed that previous version was
ignoring a case fixed by 'commit f6a1906 ("drm/i915: Do a dummy DPCD
 read before the actual read")'.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Jesse Barnes 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 85 +++--
 1 file changed, 30 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0febf8d..f305ecb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3170,40 +3170,16 @@ static void chv_dp_post_pll_disable(struct 
intel_encoder *encoder)
 }
 
 /*
- * Native read with retry for link status and receiver capability reads for
- * cases where the sink may still be asleep.
- *
- * Sinks are *supposed* to come up within 1ms from an off state, but we're also
- * supposed to retry 3 times per the spec.
- */
-static ssize_t
-intel_dp_dpcd_read_wake(struct drm_dp_aux *aux, unsigned int offset,
-   void *buffer, size_t size)
-{
-   ssize_t ret;
-   int i;
-
-   for (i = 0; i < 3; i++) {
-   ret = drm_dp_dpcd_read(aux, offset, buffer, size);
-   if (ret == size)
-   return ret;
-   msleep(1);
-   }
-
-   return ret;
-}
-
-/*
  * Fetch AUX CH registers 0x202 - 0x207 which contain
  * link status information
  */
 bool
 intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE])
 {
-   return intel_dp_dpcd_read_wake(_dp->aux,
-  DP_LANE0_1_STATUS,
-  link_status,
-  DP_LINK_STATUS_SIZE) == 
DP_LINK_STATUS_SIZE;
+   return drm_dp_dpcd_read(_dp->aux,
+   DP_LANE0_1_STATUS,
+   link_status,
+   DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
 }
 
 /* These are source-specific values. */
@@ -3838,8 +3814,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
 
-   if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
-   sizeof(intel_dp->dpcd)) < 0)
+   if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
+sizeof(intel_dp->dpcd)) < 0)
return false; /* aux transfer failed */
 
DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
intel_dp->dpcd);
@@ -3850,9 +3826,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
-   intel_dp_dpcd_read_wake(_dp->aux, DP_PSR_SUPPORT,
-   intel_dp->psr_dpcd,
-   sizeof(intel_dp->psr_dpcd));
+   drm_dp_dpcd_read(_dp->aux, DP_PSR_SUPPORT,
+intel_dp->psr_dpcd,
+sizeof(intel_dp->psr_dpcd));
if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
dev_priv->psr.sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
@@ -3863,9 +3839,9 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
uint8_t frame_sync_cap;
 
dev_priv->psr.sink_support = true;
-   intel_dp_dpcd_read_wake(_dp->aux,
-   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
-   _sync_cap, 1);
+   drm_dp_dpcd_readb(_dp->aux,
+ 

[Intel-gfx] [PATCH 5/9] drm: Wait 1ms before retrying aux transactions on EBUSY.

[Rodrigo Vivi]

DP Specs isn't really clear about the amount of retries,
but for cases it mentions retries it also mention times that
vary from 300us to 1ms.

For many cases hardware can handled the timeouts before retry
is possible and allowed, but for many other cases it is better
to wait and give time so the aux channels can recover.

For instance one general case there is when downstream device
is waking up from sleep states generating HPD so it might take
up to 1ms before getting responsive.

I believe with this msleep we could minimize the 32 times retries
and still let Dell monitors happy, but I don't have this monitor
to test here so let's just add the sleep for now and still retry
32 times.

v2: Include doc comment.
Also apply the 1ms to i2c helper.
Use usleep_range for better precision as suggested by Jani.

Cc: Jani Nikula 
Cc: Dave Airlie 
Signed-off-by: Rodrigo Vivi 
Tested-by: Daniel Stone  # v1 on SKL
---
 drivers/gpu/drm/drm_dp_helper.c | 10 +++---
 include/drm/drm_dp_helper.h |  3 ++-
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2e26097..e328715 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -202,9 +202,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
if (err == -EAGAIN)
continue;
 
-   /* FIXME: On BUSY we could wait before retrying */
-   if (err == -EBUSY)
+   /* Give a time for aux channels to recover */
+   if (err == -EBUSY) {
+   usleep_range(1000, 1000);
continue;
+   }
 
return err;
}
@@ -557,8 +559,10 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
struct drm_dp_aux_msg *msg)
 * -EAGAIN retries are handled by i2c layer with
 * timeouts for repeated -EAGAINs
 */
-   if (ret == -EBUSY)
+   if (ret == -EBUSY) {
+   usleep_range(1000, 1000);
continue;
+   }
 
DRM_DEBUG_KMS("transaction failed: %d\n", ret);
return ret;
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 518fc1b..ac9de5e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -757,7 +757,8 @@ struct drm_dp_aux {
 * - -EPROTO: On a short, helpers will return -EPROTO to make it simpler
 *   to check for failure.
 * - -EBUSY: When BUSY helpers will attempt retries before propagating
-*   this error.
+*   this error, with 1ms between attempts to give a time for downstream
+*   devices to recover.
 * - -EAGAIN: DPCD helper will attempt immediatelly retries before
 *   propagating this error. i2c helper will only propagate directly
 *   since i2c layer already perform retries with timeouts for repeated
-- 
2.4.3

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

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

[Goel, Akash]

On 11/25/2015 10:58 PM, Chris Wilson wrote:

On Wed, Nov 25, 2015 at 01:02:20PM +0200, Ville Syrjälä wrote:

On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:

On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:

On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:

On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:

From: Akash Goel 

When the object is moved out of CPU read domain, the cachelines
are not invalidated immediately. The invalidation is deferred till
next time the object is brought back into CPU read domain.
But the invalidation is done unconditionally, i.e. even for the case
where the cachelines were flushed previously, when the object moved out
of CPU write domain. This is avoidable and would lead to some optimization.
Though this is not a hypothetical case, but is unlikely to occur often.
The aim is to detect changes to the backing storage whilst the
data is potentially in the CPU cache, and only clflush in those case.

Signed-off-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_drv.h | 1 +
  drivers/gpu/drm/i915/i915_gem.c | 9 -
  2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index df9316f..fedb71d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
unsigned long gt_ro:1;
unsigned int cache_level:3;
unsigned int cache_dirty:1;
+   unsigned int cache_clean:1;


So now we have cache_dirty and cache_clean which seems redundant,
except somehow cache_dirty != !cache_clean?


Exactly, not entirely redundant. I did think something along MESI lines
would be useful, but that didn't capture the different meanings we
employ.

cache_dirty tracks whether we have been eliding the clflush.

cache_clean tracks whether we know the cache has been completely
clflushed.


Can we know that with speculative prefetching and whatnot?


"The memory attribute of the page containing the affected line has no
effect on the behavior of this instruction. It should be noted that
processors are free to speculative fetch and cache data from system
memory regions assigned a memory-type allowing for speculative reads
(i.e. WB, WC, WT memory types). The Streaming SIMD Extensions PREFETCHh
instruction is considered a hint to this speculative behavior. Because
this speculative fetching can occur at any time and is not tied to
instruction execution, CLFLUSH is not ordered with respect to PREFETCHh
or any of the speculative fetching mechanisms (that is, data could be
speculative loaded into the cache just before, during, or after the
execution of a CLFLUSH to that cache line)."

which taken to the extreme means that we can't get away with this trick.

If we can at least guarantee that such speculation can't extend beyond
a page boundary that will be enough to assert that the patch is valid.

Hopefully someone knows a CPU guru or two.


Found some relevant info at the link https://lwn.net/Articles/255364/

An excerpt from the same link
Hardware Prefetching
"Prefetching has one big weakness: it cannot cross page boundaries. The 
reason should be obvious when one realizes that the CPUs support demand 
paging. If the prefetcher were allowed to cross page boundaries, the 
access might trigger an OS event to make the page available. This by 
itself can be bad, especially for performance. What is worse is that the 
prefetcher does not know about the semantics of the program or the OS 
itself. It might therefore prefetch pages which, in real life, never 
would be requested. That means the prefetcher would run past the end of 
the memory region the processor accessed in a recognizable pattern 
before. This is not only possible, it is very likely. If the processor, 
as a side effect of a prefetch, triggered a request for such a page the 
OS might even be completely thrown off its tracks if such a request 
could never otherwise happen.


It is therefore important to realize that, regardless of how good the 
prefetcher is at predicting the pattern, the program will experience 
cache misses at page boundaries unless it explicitly prefetches or reads 
from the new page. This is another reason to optimize the layout of data 
as described in Section 6.2 to minimize cache pollution by keeping 
unrelated data out.


Because of this page limitation the processors do not have terribly 
sophisticated logic to recognize prefetch patterns. With the still 
predominant 4k page size there is only so much which makes sense. The 
address range in which strides are recognized has been increased over 
the years, but it probably does not make much sense to go beyond the 512 
byte window which is often used today. Currently prefetch units do not 
recognize non-linear access pattern"



Best regards
Akash


-Chris

[Intel-gfx] [PATCH] drm/i915: Fix up -EIO ABI per igt/gem_eio

[Daniel Vetter]

My apologies to Chris Wilson for being dense on this topic for
essentially for years.

This patch doesn't do any big redesign of the overall reset flow, but
instead just applies changes where it's needed to obey gem_eio. We can
redesign later on, but for now I prefer to make the testcase happy
with some minimally invasive changes:

- Ensure that set_domain_ioctl never returns -EIO. Tricky part there
  is that we might race with the reset handler when doing the lockless
  wait.

- Make sure debugfs/i915_wedged is actually useful to reset a wedged
  gpu - atm it bails out with -EAGAIN for a terminally wedged gpu.
  That's because reset_in_progress actually includes that terminal
  state, which is super-confusing (and most callers got this wrong).
  Fix this by changing the semantics of reset_in_progress to do what
  it says on the tin (and fixup all other callers).

  Also make sure that reset_in_progress is cleared when we reach the
  terminal "wedged" state. Without this we kept returning -EAGAIN in
  some places forever.

- Second problem with debugfs/i915_wedge was that we never got out of
  the terminal wedged state. Hence manually set the reset counter out
  of that state before starting the hung gpu recovery.

  For safety also make sure that we are consintent with resetting the
  gpu between i915_reset_and_wakeup and i915_handler_error by just
  passing the boolean "wedged" around instead of trying to recompute
  it wrongly. This isn't an issue for gem_eio with the debugfs fix,
  but just general robustness of the code.

- Finally make sure that when gpu reset is disabled through the module
  paramter the kernel doesn't generate dmesg noise that would upset
  our CI/piglit. Simplest solution for that was to lift the i915.reset
  check up into i915_reset().

With all these changes, plus the igt fixes I've posted, gem_eio is now
happy on many snb.

v2: Don't upset lockdep with my set_domain_ioctl changes.

Cc: Chris Wilson 
Testcase: igt/gem_eio/*
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  4 
 drivers/gpu/drm/i915/i915_drv.c |  6 ++
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 23 +++
 drivers/gpu/drm/i915/i915_irq.c | 11 ++-
 drivers/gpu/drm/i915/intel_uncore.c |  3 ---
 6 files changed, 32 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 411a9c68b4ee..c4006c09ef1b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4744,6 +4744,10 @@ i915_wedged_set(void *data, u64 val)
if (i915_reset_in_progress(_priv->gpu_error))
return -EAGAIN;
 
+   /* Already wedged, force us out of this terminal state. */
+   if (i915_terminally_wedged(_priv->gpu_error))
+   atomic_set(_priv->gpu_error.reset_counter, 0);
+
intel_runtime_pm_get(dev_priv);
 
i915_handle_error(dev, val,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ec1e877c4a36..1f5386bb78f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -909,6 +909,12 @@ int i915_reset(struct drm_device *dev)
 
simulated = dev_priv->gpu_error.stop_rings != 0;
 
+   if (!i915.reset) {
+   DRM_INFO("GPU reset disabled in module option, not 
resetting\n");
+   mutex_unlock(>struct_mutex);
+   return -ENODEV;
+   }
+
ret = intel_gpu_reset(dev);
 
/* Also reset the gpu hangman. */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a47e0f4fab56..8876b4891d56 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2939,7 +2939,7 @@ int __must_check i915_gem_check_wedge(struct 
i915_gpu_error *error,
 static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
 {
return unlikely(atomic_read(>reset_counter)
-   & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
+   & I915_RESET_IN_PROGRESS_FLAG);
 }
 
 static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f10a5d57377e..f794e8f37f92 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -85,8 +85,7 @@ i915_gem_wait_for_error(struct i915_gpu_error *error)
 {
int ret;
 
-#define EXIT_COND (!i915_reset_in_progress(error) || \
-  i915_terminally_wedged(error))
+#define EXIT_COND (!i915_reset_in_progress(error))
if (EXIT_COND)
return 0;
 
@@ -1113,16 +1112,16 @@ int
 i915_gem_check_wedge(struct i915_gpu_error *error,
 bool interruptible)
 {
+   /* Recovery complete, but the reset failed ... */
+   if (i915_terminally_wedged(error))
+ 

[Intel-gfx] [PATCH v2] drm/i915/guc: Clean up locks in GuC

[yu . dai]

From: Alex Dai 

When GuC Work Queue is full, driver will wait GuC for avaliable
space by delaying 1ms. The wait needs to be out of spinlockirq /
unlock. Otherwise, lockup happens because jiffies won't be updated
dur to irq is disabled. The unnecessary locks has been cleared.
dev->struct_mutex is used instead where needed.

Issue is found in igt/gem_close_race.

v2: Clean up wq_lock too
v1: Clean up host2guc lock as well

Signed-off-by: Alex Dai 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c | 32 +++---
 drivers/gpu/drm/i915/intel_guc.h   |  4 
 3 files changed, 13 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a728ff1..d6b7817 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2473,15 +2473,15 @@ static int i915_guc_info(struct seq_file *m, void *data)
if (!HAS_GUC_SCHED(dev_priv->dev))
return 0;
 
+   if (mutex_lock_interruptible(>struct_mutex))
+   return 0;
+
/* Take a local copy of the GuC data, so we can dump it at leisure */
-   spin_lock(_priv->guc.host2guc_lock);
guc = dev_priv->guc;
-   if (guc.execbuf_client) {
-   spin_lock(_client->wq_lock);
+   if (guc.execbuf_client)
client = *guc.execbuf_client;
-   spin_unlock(_client->wq_lock);
-   }
-   spin_unlock(_priv->guc.host2guc_lock);
+
+   mutex_unlock(>struct_mutex);
 
seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ed9f100..97996e5 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -86,7 +86,6 @@ static int host2guc_action(struct intel_guc *guc, u32 *data, 
u32 len)
return -EINVAL;
 
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
-   spin_lock(_priv->guc.host2guc_lock);
 
dev_priv->guc.action_count += 1;
dev_priv->guc.action_cmd = data[0];
@@ -119,7 +118,6 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
}
dev_priv->guc.action_status = status;
 
-   spin_unlock(_priv->guc.host2guc_lock);
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
 
return ret;
@@ -249,6 +247,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
}
 
kunmap_atomic(base);
+
return ret;
 }
 
@@ -292,16 +291,12 @@ static uint32_t select_doorbell_cacheline(struct 
intel_guc *guc)
const uint32_t cacheline_size = cache_line_size();
uint32_t offset;
 
-   spin_lock(>host2guc_lock);
-
/* Doorbell uses a single cache line within a page */
offset = offset_in_page(guc->db_cacheline);
 
/* Moving to next cache line to reduce contention */
guc->db_cacheline += cacheline_size;
 
-   spin_unlock(>host2guc_lock);
-
DRM_DEBUG_DRIVER("selected doorbell cacheline 0x%x, next 0x%x, linesize 
%u\n",
offset, guc->db_cacheline, cacheline_size);
 
@@ -322,13 +317,11 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
const uint16_t end = start + half;
uint16_t id;
 
-   spin_lock(>host2guc_lock);
id = find_next_zero_bit(guc->doorbell_bitmap, end, start);
if (id == end)
id = GUC_INVALID_DOORBELL_ID;
else
bitmap_set(guc->doorbell_bitmap, id, 1);
-   spin_unlock(>host2guc_lock);
 
DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
hi_pri ? "high" : "normal", id);
@@ -338,9 +331,7 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
 
 static void release_doorbell(struct intel_guc *guc, uint16_t id)
 {
-   spin_lock(>host2guc_lock);
bitmap_clear(guc->doorbell_bitmap, id, 1);
-   spin_unlock(>host2guc_lock);
 }
 
 /*
@@ -487,16 +478,13 @@ static int guc_get_workqueue_space(struct i915_guc_client 
*gc, u32 *offset)
struct guc_process_desc *desc;
void *base;
u32 size = sizeof(struct guc_wq_item);
-   int ret = 0, timeout_counter = 200;
+   int ret = -ETIMEDOUT, timeout_counter = 200;
 
base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, 0));
desc = base + gc->proc_desc_offset;
 
while (timeout_counter-- > 0) {
-   ret = wait_for_atomic(CIRC_SPACE(gc->wq_tail, desc->head,
-   gc->wq_size) >= size, 1);
-
-   if (!ret) {
+   if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) {
*offset = gc->wq_tail;
 

Re: [Intel-gfx] [PATCH v3] drm/i915: Eliminate vmap overhead for cmd parser

[Ville Syrjälä]

On Fri, Nov 20, 2015 at 03:31:23PM +, Chris Wilson wrote:
> With a little complexity to handle cmds straddling page boundaries, we
> can completely avoiding having to vmap the batch and the shadow batch
> objects whilst running the command parser.
> 
> On ivb i7-3720MQ:
> 
> x11perf -dot before 54.3M, after 53.2M (max 203M)
> glxgears before 7110 fps, after 7300 fps (max 7860 fps)
> 
> Before:
> Time to blt 16384 bytes x  1:  12.400µs, 1.2GiB/s
> Time to blt 16384 bytes x   4096:   3.055µs, 5.0GiB/s
> 
> After:
> Time to blt 16384 bytes x  1:   8.600µs, 1.8GiB/s
> Time to blt 16384 bytes x   4096:   2.456µs, 6.2GiB/s
> 
> Removing the vmap is mostly a win, except we lose in a few cases where
> the batch size is greater than a page due to the extra complexity (loss
> of a simple cache efficient large copy, and boundary handling).
> 
> v2: Reorder so that we do check oacontrol remaining set at end-of-batch
> v3: Stage the copy through a temporary page so that we only copy into
> dst commands that have been verified.
> v4: Move the batch offset/length validation to execbuf.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_cmd_parser.c | 258 
> -
>  1 file changed, 127 insertions(+), 131 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 814d894ed925..86910e17505a 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -860,100 +860,6 @@ find_reg(const struct drm_i915_reg_descriptor *table,
>   return NULL;
>  }
>  
> -static u32 *vmap_batch(struct drm_i915_gem_object *obj,
> -unsigned start, unsigned len)
> -{
> - int i;
> - void *addr = NULL;
> - struct sg_page_iter sg_iter;
> - int first_page = start >> PAGE_SHIFT;
> - int last_page = (len + start + 4095) >> PAGE_SHIFT;
> - int npages = last_page - first_page;
> - struct page **pages;
> -
> - pages = drm_malloc_ab(npages, sizeof(*pages));
> - if (pages == NULL) {
> - DRM_DEBUG_DRIVER("Failed to get space for pages\n");
> - goto finish;
> - }
> -
> - i = 0;
> - for_each_sg_page(obj->pages->sgl, _iter, obj->pages->nents, 
> first_page) {
> - pages[i++] = sg_page_iter_page(_iter);
> - if (i == npages)
> - break;
> - }
> -
> - addr = vmap(pages, i, 0, PAGE_KERNEL);
> - if (addr == NULL) {
> - DRM_DEBUG_DRIVER("Failed to vmap pages\n");
> - goto finish;
> - }
> -
> -finish:
> - if (pages)
> - drm_free_large(pages);
> - return (u32*)addr;
> -}
> -
> -/* Returns a vmap'd pointer to dest_obj, which the caller must unmap */
> -static u32 *copy_batch(struct drm_i915_gem_object *dest_obj,
> -struct drm_i915_gem_object *src_obj,
> -u32 batch_start_offset,
> -u32 batch_len)
> -{
> - int needs_clflush = 0;
> - void *src_base, *src;
> - void *dst = NULL;
> - int ret;
> -
> - if (batch_len > dest_obj->base.size ||
> - batch_len + batch_start_offset > src_obj->base.size)
> - return ERR_PTR(-E2BIG);
> -
> - if (WARN_ON(dest_obj->pages_pin_count == 0))
> - return ERR_PTR(-ENODEV);
> -
> - ret = i915_gem_obj_prepare_shmem_read(src_obj, _clflush);
> - if (ret) {
> - DRM_DEBUG_DRIVER("CMD: failed to prepare shadow batch\n");
> - return ERR_PTR(ret);
> - }
> -
> - src_base = vmap_batch(src_obj, batch_start_offset, batch_len);
> - if (!src_base) {
> - DRM_DEBUG_DRIVER("CMD: Failed to vmap batch\n");
> - ret = -ENOMEM;
> - goto unpin_src;
> - }
> -
> - ret = i915_gem_object_set_to_cpu_domain(dest_obj, true);
> - if (ret) {
> - DRM_DEBUG_DRIVER("CMD: Failed to set shadow batch to CPU\n");
> - goto unmap_src;
> - }
> -
> - dst = vmap_batch(dest_obj, 0, batch_len);
> - if (!dst) {
> - DRM_DEBUG_DRIVER("CMD: Failed to vmap shadow batch\n");
> - ret = -ENOMEM;
> - goto unmap_src;
> - }
> -
> - src = src_base + offset_in_page(batch_start_offset);
> - if (needs_clflush)
> - drm_clflush_virt_range(src, batch_len);
> -
> - memcpy(dst, src, batch_len);
> -
> -unmap_src:
> - vunmap(src_base);
> -unpin_src:
> - i915_gem_object_unpin_pages(src_obj);
> -
> - return ret ? ERR_PTR(ret) : dst;
> -}
> -
>  /**
>   * i915_needs_cmd_parser() - should a given ring use software command 
> parsing?
>   * @ring: the ring in question
> @@ -1097,6 +1003,7 @@ static bool check_cmd(const struct intel_engine_cs 
> *ring,
>  }
>  
>  #define LENGTH_BIAS 2
> +#define MAX_PARTIAL 256

There seems to some confusion whether this 

Re: [Intel-gfx] [PATCH] drm/i915: Fix up -EIO ABI per igt/gem_eio

[Chris Wilson]

On Wed, Nov 25, 2015 at 06:45:26PM +0100, Daniel Vetter wrote:
> My apologies to Chris Wilson for being dense on this topic for
> essentially for years.
> 
> This patch doesn't do any big redesign of the overall reset flow, but
> instead just applies changes where it's needed to obey gem_eio. We can
> redesign later on, but for now I prefer to make the testcase happy
> with some minimally invasive changes:
> 
> - Ensure that set_domain_ioctl never returns -EIO. Tricky part there
>   is that we might race with the reset handler when doing the lockless
>   wait.
> 
> - Make sure debugfs/i915_wedged is actually useful to reset a wedged
>   gpu - atm it bails out with -EAGAIN for a terminally wedged gpu.
>   That's because reset_in_progress actually includes that terminal
>   state, which is super-confusing (and most callers got this wrong).
>   Fix this by changing the semantics of reset_in_progress to do what
>   it says on the tin (and fixup all other callers).
> 
>   Also make sure that reset_in_progress is cleared when we reach the
>   terminal "wedged" state. Without this we kept returning -EAGAIN in
>   some places forever.
> 
> - Second problem with debugfs/i915_wedge was that we never got out of
>   the terminal wedged state. Hence manually set the reset counter out
>   of that state before starting the hung gpu recovery.
> 
>   For safety also make sure that we are consintent with resetting the
>   gpu between i915_reset_and_wakeup and i915_handler_error by just
>   passing the boolean "wedged" around instead of trying to recompute
>   it wrongly. This isn't an issue for gem_eio with the debugfs fix,
>   but just general robustness of the code.
> 
> - Finally make sure that when gpu reset is disabled through the module
>   paramter the kernel doesn't generate dmesg noise that would upset
>   our CI/piglit. Simplest solution for that was to lift the i915.reset
>   check up into i915_reset().
> 
> With all these changes, plus the igt fixes I've posted, gem_eio is now
> happy on many snb.
> 
> v2: Don't upset lockdep with my set_domain_ioctl changes.
> 
> Cc: Chris Wilson 
> Testcase: igt/gem_eio/*
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |  4 
>  drivers/gpu/drm/i915/i915_drv.c |  6 ++
>  drivers/gpu/drm/i915/i915_drv.h |  2 +-
>  drivers/gpu/drm/i915/i915_gem.c | 23 +++
>  drivers/gpu/drm/i915/i915_irq.c | 11 ++-
>  drivers/gpu/drm/i915/intel_uncore.c |  3 ---
>  6 files changed, 32 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 411a9c68b4ee..c4006c09ef1b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4744,6 +4744,10 @@ i915_wedged_set(void *data, u64 val)
>   if (i915_reset_in_progress(_priv->gpu_error))
>   return -EAGAIN;
>  
> + /* Already wedged, force us out of this terminal state. */
> + if (i915_terminally_wedged(_priv->gpu_error))
> + atomic_set(_priv->gpu_error.reset_counter, 0);

What?

> +
>   intel_runtime_pm_get(dev_priv);
>  
>   i915_handle_error(dev, val,
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ec1e877c4a36..1f5386bb78f4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -909,6 +909,12 @@ int i915_reset(struct drm_device *dev)
>  
>   simulated = dev_priv->gpu_error.stop_rings != 0;
>  
> + if (!i915.reset) {
> + DRM_INFO("GPU reset disabled in module option, not 
> resetting\n");
> + mutex_unlock(>struct_mutex);
> + return -ENODEV;
> + }
> +
>   ret = intel_gpu_reset(dev);

Please don't break intel_gpu_reset() like that.

I think this patch missed the point entirely.
-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 v2] drm/i915: Disable shrinker for non-swapped backed objects

[Johannes Weiner]

On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> If the system has no available swap pages, we cannot make forward
> progress in the shrinker by releasing active pages, only by releasing
> purgeable pages which are immediately reaped. Take total_swap_pages into
> account when counting up available objects to be shrunk and subsequently
> shrinking them. By doing so, we avoid unbinding objects that cannot be
> shrunk and so wasting CPU cycles flushing those objects from the GPU to
> the system and then immediately back again (as they will more than
> likely be reused shortly after).
> 
> Based on a patch by Akash Goel.
> 
> v2: Check for frontswap without physical swap (or dedicated swap space).
> If frontswap is available, we may be able to compress the GPU pages
> instead of swapping out to disk. In this case, we do want to shrink GPU
> objects and so make them available for compressing.

Frontswap always sits on top of an active swap device. It's enough to
check for available swap space.

> +static bool swap_available(void)
> +{
> + return total_swap_pages || frontswap_enabled;
> +}

If you use get_nr_swap_pages() instead of total_swap_pages, this will
also stop scanning objects once the swap space is full. We do that in
the VM to stop scanning anonymous pages.

On a sidenote, frontswap_enabled is #defined to 1 when the feature is
compiled in, so this would be a no-op on most distro kernels.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Eliminate vmap overhead for cmd parser

[Chris Wilson]

On Wed, Nov 25, 2015 at 09:51:08PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 20, 2015 at 03:31:23PM +, Chris Wilson wrote:
> > @@ -1097,6 +1003,7 @@ static bool check_cmd(const struct intel_engine_cs 
> > *ring,
> >  }
> >  
> >  #define LENGTH_BIAS 2
> > +#define MAX_PARTIAL 256
> 
> There seems to some confusion whether this is bytes or dwords.

Indeed, I can't remember of the top of my head.

(Double checked that the set of commands that I was thinking were 132
bytes.)
 
> Also I guess we already end up allocating two pages anyway, so
> maybe MAX_PARTIAL should just be one page? It's still not big
> enough to cover the max legal cmd length AFAICS, so I think
> the WARN in the check needs to be removed.

Sure, rounding up the next 8192 byte slab cache doesn't seem like it
will bite us.

So #define MAX_PARTIAL_BYTES PAGE_SIZE

> > +   in = offset_in_page(batch_start_offset);
> > +   partial = 0;
> > +   for (src_iter = batch_start_offset >> PAGE_SHIFT;
> > +src_iter < batch_obj->base.size >> PAGE_SHIFT;
> > +src_iter++) {
> 
> So we're iterating over all the pages. Should be enough to iterate
> until batch_start_offset+batch_len I suppose, but as long as we bail
> out when we run out of batch it should be fine.

Right, this was mostly convenience for writing the loop bounds - it was
more or less a simple conversion from the old iterator.

> I see there's a batch_len check at the end, but I don't see us handling
> the case when the user already gives us something with batch_len==0.
> Maybe that should be rejected somewhere higher up?

batch_len = 0 is filtered out in the caller...
 
> Also what happens if we don't find MI_BATCH_BUFFER_END before running
> out of batch? Oh, I see, we set ret=-EINVAL, and clear it to 0 when we
> find MI_BATCH_BUFFER_END. So that part seems to be fine.
> 
> > +   u32 *cmd, *page_end, *batch_end;
> > +   u32 this;
> > +
> > +   this = batch_len;
> 
> I was a bit concerned about batch_len & 3, but we already check for
> batch_len&7==0 in i915_gem_check_execbuffer(), so it should be good here.

cmdparser_assert(batch_len > 0 && (batch_len & 3) == 0);

as documentation for the contract?
-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 v2] drm/i915: Disable shrinker for non-swapped backed objects

[Chris Wilson]

On Wed, Nov 25, 2015 at 02:06:10PM -0500, Johannes Weiner wrote:
> On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> > If the system has no available swap pages, we cannot make forward
> > progress in the shrinker by releasing active pages, only by releasing
> > purgeable pages which are immediately reaped. Take total_swap_pages into
> > account when counting up available objects to be shrunk and subsequently
> > shrinking them. By doing so, we avoid unbinding objects that cannot be
> > shrunk and so wasting CPU cycles flushing those objects from the GPU to
> > the system and then immediately back again (as they will more than
> > likely be reused shortly after).
> > 
> > Based on a patch by Akash Goel.
> > 
> > v2: Check for frontswap without physical swap (or dedicated swap space).
> > If frontswap is available, we may be able to compress the GPU pages
> > instead of swapping out to disk. In this case, we do want to shrink GPU
> > objects and so make them available for compressing.
> 
> Frontswap always sits on top of an active swap device. It's enough to
> check for available swap space.
> 
> > +static bool swap_available(void)
> > +{
> > +   return total_swap_pages || frontswap_enabled;
> > +}
> 
> If you use get_nr_swap_pages() instead of total_swap_pages, this will
> also stop scanning objects once the swap space is full. We do that in
> the VM to stop scanning anonymous pages.

Thanks. Would EXPORT_SYMBOL_GPL(nr_swap_pages) (or equivalent) be
acceptable?
-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: Eliminate vmap overhead for cmd parser

[Ville Syrjälä]

On Wed, Nov 25, 2015 at 08:13:43PM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 09:51:08PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 20, 2015 at 03:31:23PM +, Chris Wilson wrote:
> > > @@ -1097,6 +1003,7 @@ static bool check_cmd(const struct intel_engine_cs 
> > > *ring,
> > >  }
> > >  
> > >  #define LENGTH_BIAS 2
> > > +#define MAX_PARTIAL 256
> > 
> > There seems to some confusion whether this is bytes or dwords.
> 
> Indeed, I can't remember of the top of my head.
> 
> (Double checked that the set of commands that I was thinking were 132
> bytes.)
>  
> > Also I guess we already end up allocating two pages anyway, so
> > maybe MAX_PARTIAL should just be one page? It's still not big
> > enough to cover the max legal cmd length AFAICS, so I think
> > the WARN in the check needs to be removed.
> 
> Sure, rounding up the next 8192 byte slab cache doesn't seem like it
> will bite us.
> 
> So #define MAX_PARTIAL_BYTES PAGE_SIZE
> 
> > > + in = offset_in_page(batch_start_offset);
> > > + partial = 0;
> > > + for (src_iter = batch_start_offset >> PAGE_SHIFT;
> > > +  src_iter < batch_obj->base.size >> PAGE_SHIFT;
> > > +  src_iter++) {
> > 
> > So we're iterating over all the pages. Should be enough to iterate
> > until batch_start_offset+batch_len I suppose, but as long as we bail
> > out when we run out of batch it should be fine.
> 
> Right, this was mostly convenience for writing the loop bounds - it was
> more or less a simple conversion from the old iterator.
> 
> > I see there's a batch_len check at the end, but I don't see us handling
> > the case when the user already gives us something with batch_len==0.
> > Maybe that should be rejected somewhere higher up?
> 
> batch_len = 0 is filtered out in the caller...

Oh yeah, see it now.

>  
> > Also what happens if we don't find MI_BATCH_BUFFER_END before running
> > out of batch? Oh, I see, we set ret=-EINVAL, and clear it to 0 when we
> > find MI_BATCH_BUFFER_END. So that part seems to be fine.
> > 
> > > + u32 *cmd, *page_end, *batch_end;
> > > + u32 this;
> > > +
> > > + this = batch_len;
> > 
> > I was a bit concerned about batch_len & 3, but we already check for
> > batch_len&7==0 in i915_gem_check_execbuffer(), so it should be good here.
> 
> cmdparser_assert(batch_len > 0 && (batch_len & 3) == 0);
> 
> as documentation for the contract?

I won't insist, but feel free to add something like that if you
wish.

-- 
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: Change context lifecycle

[Yu Dai]

On 11/25/2015 07:02 AM, Mika Kuoppala wrote:

Nick Hoath  writes:

> Use the first retired request on a new context to unpin
> the old context. This ensures that the hw context remains
> bound until it has been written back to by the GPU.
> Now that the context is pinned until later in the request/context
> lifecycle, it no longer needs to be pinned from context_queue to
> retire_requests.
>
> v2: Moved the new pin to cover GuC submission (Alex Dai)
> Moved the new unpin to request_retire to fix coverage leak
> v3: Added switch to default context if freeing a still pinned
> context just in case the hw was actually still using it
> v4: Unwrapped context unpin to allow calling without a request
> v5: Only create a switch to idle context if the ring doesn't
> already have a request pending on it (Alex Dai)
> Rename unsaved to dirty to avoid double negatives (Dave Gordon)
> Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
> Split out per engine cleanup from context_free as it
> was getting unwieldy
> Corrected locking (Dave Gordon)
>
> Signed-off-by: Nick Hoath 
> Issue: VIZ-4277
> Cc: Daniel Vetter 
> Cc: David Gordon 
> Cc: Chris Wilson 
> Cc: Alex Dai 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   1 +
>  drivers/gpu/drm/i915/i915_gem.c  |   3 +
>  drivers/gpu/drm/i915/intel_lrc.c | 124 
+++
>  drivers/gpu/drm/i915/intel_lrc.h |   1 +
>  4 files changed, 105 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d5cf30b..e82717a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -889,6 +889,7 @@ struct intel_context {
>struct {
>struct drm_i915_gem_object *state;
>struct intel_ringbuffer *ringbuf;
> +  bool dirty;
>int pin_count;
>} engine[I915_NUM_RINGS];
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e955499..3829bc1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1354,6 +1354,9 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
>  {
>trace_i915_gem_request_retire(request);
>
> +  if (i915.enable_execlists)
> +  intel_lr_context_complete_check(request);
> +
>/* We know the GPU must have read the request to have
> * sent us the seqno + interrupt, so use the position
> * of tail of the request to update the last known position
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
b/drivers/gpu/drm/i915/intel_lrc.c
> index 06180dc..03d5bca 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -566,9 +566,6 @@ static int execlists_context_queue(struct 
drm_i915_gem_request *request)
>struct drm_i915_gem_request *cursor;
>int num_elements = 0;
>
> -  if (request->ctx != ring->default_context)
> -  intel_lr_context_pin(request);
> -
>i915_gem_request_reference(request);
>
>spin_lock_irq(>execlist_lock);
> @@ -732,6 +729,13 @@ intel_logical_ring_advance_and_submit(struct 
drm_i915_gem_request *request)
>if (intel_ring_stopped(ring))
>return;
>
> +  if (request->ctx != ring->default_context) {
> +  if (!request->ctx->engine[ring->id].dirty) {
> +  intel_lr_context_pin(request);
> +  request->ctx->engine[ring->id].dirty = true;
> +  }
> +  }
> +
>if (dev_priv->guc.execbuf_client)
>i915_guc_submit(dev_priv->guc.execbuf_client, request);
>else
> @@ -958,12 +962,6 @@ void intel_execlists_retire_requests(struct 
intel_engine_cs *ring)
>spin_unlock_irq(>execlist_lock);
>
>list_for_each_entry_safe(req, tmp, _list, execlist_link) {
> -  struct intel_context *ctx = req->ctx;
> -  struct drm_i915_gem_object *ctx_obj =
> -  ctx->engine[ring->id].state;
> -
> -  if (ctx_obj && (ctx != ring->default_context))
> -  intel_lr_context_unpin(req);
>list_del(>execlist_link);
>i915_gem_request_unreference(req);
>}
> @@ -1058,21 +1056,39 @@ reset_pin_count:
>return ret;
>  }
>
> -void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
> +static void __intel_lr_context_unpin(struct intel_engine_cs *ring,
> +  struct intel_context *ctx)
>  {
> -  struct intel_engine_cs *ring = rq->ring;
> -  struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
> -  struct intel_ringbuffer *ringbuf = rq->ringbuf;
> -
> +  struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
> +  struct intel_ringbuffer *ringbuf = ctx->engine[ring->id].ringbuf;
>if (ctx_obj) {
>WARN_ON(!mutex_is_locked(>dev->struct_mutex));
> -  if 

Re: [Intel-gfx] [PATCH i-g-t] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)

[Imre Deak]

On ke, 2015-11-25 at 19:16 +0200, marius.c.v...@intel.com wrote:
> From: Marius Vlad 
> 
> Signed-off-by: Marius Vlad 
> ---
>  tests/pm_rpm.c | 120 
> +
>  1 file changed, 120 insertions(+)
> 
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index c4fb19c..157cf29 100644
> --- a/tests/pm_rpm.c
> +++ b/tests/pm_rpm.c
> @@ -1729,6 +1729,120 @@ static void planes_subtest(bool universal, bool dpms)
>   }
>  }
>  
> +static void pm_test_tiling(void)
> +{
> + uint32_t *handles;
> + uint8_t **gem_bufs;
> +
> + int max_gem_objs = 0;
> + uint8_t off_bit = 20;
> + uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
> +
> + uint32_t i, j, tiling_modes[3] = {
> + I915_TILING_NONE,
> + I915_TILING_X,
> + I915_TILING_Y,
> + };
> + uint32_t ti, sw;
> +
> + /* default value */
> + uint32_t stride = 1024;
> +
> + /* calculate how many objects we can map */
> + for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
> + ;

With these sizes we may end up with all objects properly aligned,
that's why I suggested smaller objects. Based on I830_FENCE_START_MASK
we could allocate for example starting from 16kB to 256kB.

> +
> + gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
> + handles = malloc(sizeof(uint32_t) * max_gem_objs);

Nitpick: sizeof(*ptr) is safer and you could've used calloc in both
cases.

> +
> + /* map to gtt and store some random data */
> + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
> + handles[i] = gem_create(drm_fd, j);
> + gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
> + memset(gem_bufs[i], 0x65, j);
> + }
> +
> + /* try to set different tiling for each handle */
> + for (i = 0; i < ARRAY_SIZE(tiling_modes); i++) {
> + disable_all_screens_and_wait(_data);
> +
> + for (j = 0; j < max_gem_objs; j++) {
> + gem_set_tiling(drm_fd, handles[j], tiling_modes[i], 
> stride);
> +
> + gem_get_tiling(drm_fd, handles[j], , );
> + igt_assert(tiling_modes[i] == ti);
> + }
> +
> + enable_one_screen_and_wait(_data);

Ok, but after the second iteration all objects could be properly
aligned, so it's better to close/realloc/memset the objects in each
iteration.

> + }
> +
> + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
> + igt_assert(munmap(gem_bufs[i], j) == 0);
> + gem_close(drm_fd, handles[i]);
> + }
> +
> + free(gem_bufs);
> + free(handles);
> +}
> +
> +static void pm_test_caching(void)
> +{
> + uint32_t *handles;
> + uint8_t **gem_bufs;
> + int8_t has_caching_display = -1;
> +
> + uint32_t i, j, got_caching;
> + uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
> + uint32_t cache_levels[3] = {
> + I915_CACHING_NONE,
> + I915_CACHING_CACHED,/* LLC caching */
> + I915_CACHING_DISPLAY,   /* eDRAM caching */
> + };
> +
> + int max_gem_objs = 0;
> + uint8_t off_bit = 20;
> +
> + for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
> + ;

No need to bother about alignment here, so we can just use a single
16kB object for example.

> +
> + gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
> + handles = malloc(sizeof(uint32_t) * max_gem_objs);
> +
> + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
> + handles[i] = gem_create(drm_fd, j);
> + gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
> + memset(gem_bufs[i], 0x65, j);
> + }
> +
> + /* figure out if we have cache display available on the platform */
> + gem_set_caching(drm_fd, handles[0], I915_CACHING_DISPLAY);
> + if (gem_get_caching(drm_fd, handles[0]))

No need to hardcode I915_CACHING_NONE here. Also I liked the original
version to check this everywhere better, by accepting both
CACHING_DISPLAY and CACHING_NONE as a result.

> + has_caching_display++;
> +
> + for (i = 0; i < ARRAY_SIZE(cache_levels) + has_caching_display; i++) {
> + disable_all_screens_and_wait(_data);
> +
> + for (j = 0; j < max_gem_objs; j++) {
> + gem_set_caching(drm_fd, handles[j], cache_levels[i]);
> +
> + igt_debug("Verying cache for handle %u, level %u\n", j, 
> i);
> + got_caching = gem_get_caching(drm_fd, handles[j]);
> +
> + igt_assert(got_caching == cache_levels[i]);
> + }
> +
> + enable_one_screen_and_wait(_data);

The object can be unbound after the IOCTL so you need to do a memset at
the begin of each iteration.

> + }
> +
> 

Re: [Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects

[Johannes Weiner]

On Wed, Nov 25, 2015 at 08:31:02PM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 02:06:10PM -0500, Johannes Weiner wrote:
> > On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> > > +static bool swap_available(void)
> > > +{
> > > + return total_swap_pages || frontswap_enabled;
> > > +}
> > 
> > If you use get_nr_swap_pages() instead of total_swap_pages, this will
> > also stop scanning objects once the swap space is full. We do that in
> > the VM to stop scanning anonymous pages.
> 
> Thanks. Would EXPORT_SYMBOL_GPL(nr_swap_pages) (or equivalent) be
> acceptable?

No opposition from me. Just please add a small comment that this is
for shrinkers with swappable objects.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle

[Yu Dai]

OK, here is my understanding. We do context pin/unpin during create/free 
request or during submit/retire request but with condition (dirty) 
check. So the context pincount will be # of requests plus 1, if it is 
dirty. Dirty means that context likely is accessed by HW, while 
not-dirty means HW is not accessing the lrc at that moment. This extra 
pincount will be held until we receive retire of request from a 
different context.


The switch to idle context and wait looks good to me too. I tested it 
out and it fixes the hang issue when GuC is enabled.


Reviewed-by: Alex Dai 

Thanks,
Alex

On 11/25/2015 04:57 AM, Nick Hoath wrote:

Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
retire_requests.

v2: Moved the new pin to cover GuC submission (Alex Dai)
 Moved the new unpin to request_retire to fix coverage leak
v3: Added switch to default context if freeing a still pinned
 context just in case the hw was actually still using it
v4: Unwrapped context unpin to allow calling without a request
v5: Only create a switch to idle context if the ring doesn't
 already have a request pending on it (Alex Dai)
 Rename unsaved to dirty to avoid double negatives (Dave Gordon)
 Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
 Split out per engine cleanup from context_free as it
 was getting unwieldy
 Corrected locking (Dave Gordon)

Signed-off-by: Nick Hoath 
Issue: VIZ-4277
Cc: Daniel Vetter 
Cc: David Gordon 
Cc: Chris Wilson 
Cc: Alex Dai 
---
  drivers/gpu/drm/i915/i915_drv.h  |   1 +
  drivers/gpu/drm/i915/i915_gem.c  |   3 +
  drivers/gpu/drm/i915/intel_lrc.c | 124 +++
  drivers/gpu/drm/i915/intel_lrc.h |   1 +
  4 files changed, 105 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d5cf30b..e82717a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -889,6 +889,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+   bool dirty;
int pin_count;
} engine[I915_NUM_RINGS];
  
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c

index e955499..3829bc1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1354,6 +1354,9 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
  {
trace_i915_gem_request_retire(request);
  
+	if (i915.enable_execlists)

+   intel_lr_context_complete_check(request);
+
/* We know the GPU must have read the request to have
 * sent us the seqno + interrupt, so use the position
 * of tail of the request to update the last known position
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 06180dc..03d5bca 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -566,9 +566,6 @@ static int execlists_context_queue(struct 
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
  
-	if (request->ctx != ring->default_context)

-   intel_lr_context_pin(request);
-
i915_gem_request_reference(request);
  
  	spin_lock_irq(>execlist_lock);

@@ -732,6 +729,13 @@ intel_logical_ring_advance_and_submit(struct 
drm_i915_gem_request *request)
if (intel_ring_stopped(ring))
return;
  
+	if (request->ctx != ring->default_context) {

+   if (!request->ctx->engine[ring->id].dirty) {
+   intel_lr_context_pin(request);
+   request->ctx->engine[ring->id].dirty = true;
+   }
+   }
+
if (dev_priv->guc.execbuf_client)
i915_guc_submit(dev_priv->guc.execbuf_client, request);
else
@@ -958,12 +962,6 @@ void intel_execlists_retire_requests(struct 
intel_engine_cs *ring)
spin_unlock_irq(>execlist_lock);
  
  	list_for_each_entry_safe(req, tmp, _list, execlist_link) {

-   struct intel_context *ctx = req->ctx;
-   struct drm_i915_gem_object *ctx_obj =
-   ctx->engine[ring->id].state;
-
-   if (ctx_obj && (ctx != ring->default_context))
-   intel_lr_context_unpin(req);
list_del(>execlist_link);
i915_gem_request_unreference(req);
}
@@ -1058,21 +1056,39 @@ reset_pin_count:
return ret;
  }
  
-void 

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Thu, 26 Nov 2015 07:06:56 +0100,
Zhang, Xiong Y wrote:
> 
> > On Wed, 25 Nov 2015 11:57:13 +0100,
> > Zhang, Xiong Y wrote:
> > >
> > > > On Wed, 25 Nov 2015 10:56:51 +0100,
> > > > Zhang, Xiong Y wrote:
> > > > >
> > > > > Recently I always see the following error message during S4 or S3 
> > > > > resume
> > > > with drm-intel-nightly.
> > > > > [   97.778063] PM: Syncing filesystems ... done.
> > > > > [   97.801550] Freezing user space processes ... (elapsed 0.002 
> > > > > seconds)
> > > > done.
> > > > > [   97.804297] PM: Marking nosave pages: [mem
> > 0x-0x0fff]
> > > > > [   97.804302] PM: Marking nosave pages: [mem
> > 0x00058000-0x00058fff]
> > > > > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
> > > > > [   97.804310] PM: Marking nosave pages: [mem
> > 0x84c11000-0x84c12fff]
> > > > > [   97.804312] PM: Marking nosave pages: [mem
> > 0x876fc000-0x87746fff]
> > > > > [   97.804317] PM: Marking nosave pages: [mem
> > 0x8785e000-0x87fe9fff]
> > > > > [   97.804387] PM: Marking nosave pages: [mem 0x8800-0x]
> > > > > [   97.806363] PM: Basic memory bitmaps created
> > > > > [   97.806409] PM: Preallocating image memory... done (allocated
> > 321557
> > > > pages)
> > > > > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> > > > MB/s)
> > > > > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001
> > seconds)
> > > > done.
> > > > > [   98.151998] Suspending console(s) (use no_console_suspend to
> > debug)
> > > > > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi
> > hdaudioC0D2:
> > > > HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > > > > [   99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2,
> > last
> > > > cmd=0x206f2e08
> > > > > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size
> > is 0,
> > > > force 128
> > > > > [  101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout,
> > > > switching to polling mode: last cmd=0x206f2f00
> > > > > [  102.195492] snd_hda_intel :00:1f.3: No response from codec,
> > > > disabling MSI: last cmd=0x206f2f00
> > > > > [  103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout,
> > > > switching to single_cmd mode: last cmd=0x206f2f00
> > > > > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> > > > >
> > > > > The bisect result points to this commit.
> > > > > I checked this patch and had one question: if i915 driver wake up 
> > > > > ahead of
> > > > snd_hda_intel driver during resume,  i915 driver will call audio 
> > > > driver's
> > > > hdmi_present_sense() function through this patch, but the audio 
> > > > interrupt
> > is
> > > > disabled at this moment, how could hdmi_present_sense() get the
> > response
> > > > from codec ?
> > > >
> > > > Yeah, a bad thing happens there.  The fix should be simple like below,
> > > > though.  Basically the pins are checked in the resume callback in
> > > > anyway, so there is no need to handle the notification during PM.
> > > >
> > > > Could you check whether it works?
> > > >
> > > >
> > > > thanks,
> > > >
> > > > Takashi
> > >
> > > Strange, your patch couldn't get away the error message.
> > 
> > OK, then it's not about the race *during* the hd-audio driver
> > resuming or such.  I guess it's the other way round: the i915 driver
> > notifies it unnecessarily while it's getting off.  The audio part of
> > HDMI controller relies on the i915 power state, so it's screwed up.
> > 
> > Check with drm.debug option to see in which code path it's triggered.
> > If it's a call in i915 suspend, the call should be removed not to wake
> > up the audio part unnecessarily.
> 
> [Zhang, Xiong Y] it is called in intel_audio_codec_disable() from i915 
> suspend.

So the call of eld_notifier should be suppressed at suspend.

> ---
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index bdb6f226d006..b468fe0e6195 100644
> --- 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix the SDE irq dmesg warnings properly

[Ville Syrjälä]

On Wed, Nov 25, 2015 at 04:47:22PM +0200, Jani Nikula wrote:
> We had the "The master control interrupt lied (SDE)!" check and error
> message in place for a long time without any problems, until
> 
> commit aaf5ec2e51ab1d9c5e962b4728a1107ed3ff7a3e
> Author: Sonika Jindal 
> Date:   Wed Jul 8 17:07:47 2015 +0530
> 
> drm/i915: Handle HPD when it has actually occurred
> 
> caused the errors to start happening. This was bisected and reported,
> but the error message was silenced in
> 
> commit 97e5eddcc5300a0f59a55248cd243937a8ab
> Author: Daniel Vetter 
> Date:   Fri Oct 23 10:56:12 2015 +0200
> 
> drm/i915: shut up gen8+ SDE irq dmesg noise
> 
> shooting the messenger while the debugging for why Sonika's commit
> triggered the errors was still in progress.
> 
> It looks like we need to read and acknowledge the PCH_PORT_HOTPLUG
> register even though the hotplug trigger indicates there isn't a hotplug
> irq to handle.
> 
> Cc: Ville Syrjälä 
> Cc: Sonika Jindal 
> Cc: Daniel Vetter 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084
> Fixes: aaf5ec2e51ab ("drm/i915: Handle HPD when it has actually occurred")
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index c8ba94968aaf..982951d3153a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1825,7 +1825,17 @@ static void ibx_hpd_irq_handler(struct drm_device 
> *dev, u32 hotplug_trigger,
>   u32 dig_hotplug_reg, pin_mask = 0, long_mask = 0;
>  
>   dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
> + if (!hotplug_trigger) {
> + u32 mask = PORTA_HOTPLUG_STATUS_MASK |
> + PORTD_HOTPLUG_STATUS_MASK |
> + PORTC_HOTPLUG_STATUS_MASK |
> + PORTB_HOTPLUG_STATUS_MASK;
> + dig_hotplug_reg &= ~mask;
> + }
> +
>   I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
> + if (!hotplug_trigger)
> + return;

I would add some kind of comment around these parts to explain that
somehow the PCH doesn't seem to really ack the interrupt to the CPU
unless we touch the hotplug register.

Otherwise (for both patches)
Reviewed-by: Ville Syrjälä 

Also not sure if SKL might need something similar as well...

>  
>   intel_get_hpd_pins(_mask, _mask, hotplug_trigger,
>  dig_hotplug_reg, hpd,
> @@ -1840,8 +1850,7 @@ static void ibx_irq_handler(struct drm_device *dev, u32 
> pch_iir)
>   int pipe;
>   u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK;
>  
> - if (hotplug_trigger)
> - ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_ibx);
> + ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_ibx);
>  
>   if (pch_iir & SDE_AUDIO_POWER_MASK) {
>   int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK) >>
> @@ -1934,8 +1943,7 @@ static void cpt_irq_handler(struct drm_device *dev, u32 
> pch_iir)
>   int pipe;
>   u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
>  
> - if (hotplug_trigger)
> - ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_cpt);
> + ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_cpt);
>  
>   if (pch_iir & SDE_AUDIO_POWER_MASK_CPT) {
>   int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK_CPT) >>
> -- 
> 2.1.4

-- 
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: Don't compare has_drrs strictly in pipe config

[Daniel Vetter]

On Wed, Nov 25, 2015 at 03:26:47PM +0100, Takashi Iwai wrote:
> The commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in
> pipe_config_compare, v2] relaxed the way to compare the pipe
> configurations, but one new comparison sneaked in there: it added the
> strict has_drrs value check.  This causes a regression on many
> machines, typically HP laptops with a docking port, where the kernel
> spews warnings and eventually fails to set the mode properly like:
>  [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs 
> (expected 1, found 0)
>  [ cut here ]
>  WARNING: CPU: 0 PID: 79 at drivers/gpu/drm/i915/intel_display.c:12700 
> intel_modeset_check_state+0x5aa/0x870 [i915]()
>  pipe state doesn't match!
>  
> 
> This patch just removes the check again for fixing the regression.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104041
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92456
> Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=956397
> Fixes: cfb23ed622d0 ('drm/i915: Allow fuzzy matching in pipe_config_compare, 
> v2')
> Cc:  # v4.3+
> Reported-and-tested-by: Max Lin 
> Signed-off-by: Takashi Iwai 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 71860f8680f9..12a2e9d1f633 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12460,7 +12460,6 @@ intel_pipe_config_compare(struct drm_device *dev,
>   if (INTEL_INFO(dev)->gen < 8) {
>   PIPE_CONF_CHECK_M_N(dp_m_n);
>  
> - PIPE_CONF_CHECK_I(has_drrs);
>   if (current_config->has_drrs)
>   PIPE_CONF_CHECK_M_N(dp_m2_n2);
>   } else
> -- 
> 2.6.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle

[Mika Kuoppala]

Nick Hoath  writes:

> Use the first retired request on a new context to unpin
> the old context. This ensures that the hw context remains
> bound until it has been written back to by the GPU.
> Now that the context is pinned until later in the request/context
> lifecycle, it no longer needs to be pinned from context_queue to
> retire_requests.
>
> v2: Moved the new pin to cover GuC submission (Alex Dai)
> Moved the new unpin to request_retire to fix coverage leak
> v3: Added switch to default context if freeing a still pinned
> context just in case the hw was actually still using it
> v4: Unwrapped context unpin to allow calling without a request
> v5: Only create a switch to idle context if the ring doesn't
> already have a request pending on it (Alex Dai)
> Rename unsaved to dirty to avoid double negatives (Dave Gordon)
> Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
> Split out per engine cleanup from context_free as it
> was getting unwieldy
> Corrected locking (Dave Gordon)
>
> Signed-off-by: Nick Hoath 
> Issue: VIZ-4277
> Cc: Daniel Vetter 
> Cc: David Gordon 
> Cc: Chris Wilson 
> Cc: Alex Dai 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   1 +
>  drivers/gpu/drm/i915/i915_gem.c  |   3 +
>  drivers/gpu/drm/i915/intel_lrc.c | 124 
> +++
>  drivers/gpu/drm/i915/intel_lrc.h |   1 +
>  4 files changed, 105 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d5cf30b..e82717a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -889,6 +889,7 @@ struct intel_context {
>   struct {
>   struct drm_i915_gem_object *state;
>   struct intel_ringbuffer *ringbuf;
> + bool dirty;
>   int pin_count;
>   } engine[I915_NUM_RINGS];
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index e955499..3829bc1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1354,6 +1354,9 @@ static void i915_gem_request_retire(struct 
> drm_i915_gem_request *request)
>  {
>   trace_i915_gem_request_retire(request);
>  
> + if (i915.enable_execlists)
> + intel_lr_context_complete_check(request);
> +
>   /* We know the GPU must have read the request to have
>* sent us the seqno + interrupt, so use the position
>* of tail of the request to update the last known position
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 06180dc..03d5bca 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -566,9 +566,6 @@ static int execlists_context_queue(struct 
> drm_i915_gem_request *request)
>   struct drm_i915_gem_request *cursor;
>   int num_elements = 0;
>  
> - if (request->ctx != ring->default_context)
> - intel_lr_context_pin(request);
> -
>   i915_gem_request_reference(request);
>  
>   spin_lock_irq(>execlist_lock);
> @@ -732,6 +729,13 @@ intel_logical_ring_advance_and_submit(struct 
> drm_i915_gem_request *request)
>   if (intel_ring_stopped(ring))
>   return;
>  
> + if (request->ctx != ring->default_context) {
> + if (!request->ctx->engine[ring->id].dirty) {
> + intel_lr_context_pin(request);
> + request->ctx->engine[ring->id].dirty = true;
> + }
> + }
> +
>   if (dev_priv->guc.execbuf_client)
>   i915_guc_submit(dev_priv->guc.execbuf_client, request);
>   else
> @@ -958,12 +962,6 @@ void intel_execlists_retire_requests(struct 
> intel_engine_cs *ring)
>   spin_unlock_irq(>execlist_lock);
>  
>   list_for_each_entry_safe(req, tmp, _list, execlist_link) {
> - struct intel_context *ctx = req->ctx;
> - struct drm_i915_gem_object *ctx_obj =
> - ctx->engine[ring->id].state;
> -
> - if (ctx_obj && (ctx != ring->default_context))
> - intel_lr_context_unpin(req);
>   list_del(>execlist_link);
>   i915_gem_request_unreference(req);
>   }
> @@ -1058,21 +1056,39 @@ reset_pin_count:
>   return ret;
>  }
>  
> -void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
> +static void __intel_lr_context_unpin(struct intel_engine_cs *ring,
> + struct intel_context *ctx)
>  {
> - struct intel_engine_cs *ring = rq->ring;
> - struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
> - struct intel_ringbuffer *ringbuf = rq->ringbuf;
> -
> + struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
> + struct intel_ringbuffer *ringbuf = 

[Intel-gfx] [PATCH] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling

[ville . syrjala]

From: Ville Syrjälä 

LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
for transocoder B/C. And more importnatnly we should not consider
the state of underrun reporting for transcoders B/C when checking
whether we can enable the south error interrupt.

The whole thing is a bit of mess since we store the underrun reporting
state for transcoder A under intel_crtc for pipe A, irrespective of
which pipe may actually be driving the transcoder. But I figured trying
to change that would result in more churn.

Caveat: totally untested due to lack of hw, but might explain some of
the HSW/BDW BAT fails...

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

diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c 
b/drivers/gpu/drm/i915/intel_fifo_underrun.c
index bda526660e20..04bf625a1b6c 100644
--- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
@@ -48,6 +48,13 @@
  * The code also supports underrun detection on the PCH transcoder.
  */
 
+static bool cpt_transcoder_exists(struct drm_i915_private *dev_priv,
+ enum transcoder pch_transcoder)
+{
+   /* HSW/BDW have only transcoder A */
+   return !HAS_DDI(dev_priv) || pch_transcoder == TRANSCODER_A;
+}
+
 static bool ivb_can_enable_err_int(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -69,13 +76,16 @@ static bool ivb_can_enable_err_int(struct drm_device *dev)
 static bool cpt_can_enable_serr_int(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   enum pipe pipe;
-   struct intel_crtc *crtc;
+   enum transcoder pch_transcoder;
 
assert_spin_locked(_priv->irq_lock);
 
-   for_each_pipe(dev_priv, pipe) {
-   crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
+   for_each_pipe(dev_priv, pch_transcoder) {
+   struct intel_crtc *crtc =
+   
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pch_transcoder]);
+
+   if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
+   continue;
 
if (crtc->pch_fifo_underrun_disabled)
return false;
@@ -206,6 +216,9 @@ static void cpt_check_pch_fifo_underruns(struct intel_crtc 
*crtc)
 
assert_spin_locked(_priv->irq_lock);
 
+   if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
+   return;
+
if ((serr_int & SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder)) == 0)
return;
 
@@ -222,6 +235,9 @@ static void cpt_set_fifo_underrun_reporting(struct 
drm_device *dev,
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
+   return;
+
if (enable) {
I915_WRITE(SERR_INT,
   SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
-- 
2.4.10

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

Re: [Intel-gfx] [PATCH] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling

[Ville Syrjälä]

On Wed, Nov 25, 2015 at 05:11:23PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
> for transocoder B/C. And more importnatnly we should not consider
> the state of underrun reporting for transcoders B/C when checking
> whether we can enable the south error interrupt.
> 
> The whole thing is a bit of mess since we store the underrun reporting
> state for transcoder A under intel_crtc for pipe A, irrespective of
> which pipe may actually be driving the transcoder. But I figured trying
> to change that would result in more churn.
> 
> Caveat: totally untested due to lack of hw, but might explain some of
> the HSW/BDW BAT fails...

Hmm. Actually it can't since we don't use the CRCs that get signalled
via the south error interrupt. Back to the drawing board...

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_fifo_underrun.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c 
> b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> index bda526660e20..04bf625a1b6c 100644
> --- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
> +++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
> @@ -48,6 +48,13 @@
>   * The code also supports underrun detection on the PCH transcoder.
>   */
>  
> +static bool cpt_transcoder_exists(struct drm_i915_private *dev_priv,
> +   enum transcoder pch_transcoder)
> +{
> + /* HSW/BDW have only transcoder A */
> + return !HAS_DDI(dev_priv) || pch_transcoder == TRANSCODER_A;
> +}
> +
>  static bool ivb_can_enable_err_int(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -69,13 +76,16 @@ static bool ivb_can_enable_err_int(struct drm_device *dev)
>  static bool cpt_can_enable_serr_int(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - enum pipe pipe;
> - struct intel_crtc *crtc;
> + enum transcoder pch_transcoder;
>  
>   assert_spin_locked(_priv->irq_lock);
>  
> - for_each_pipe(dev_priv, pipe) {
> - crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> + for_each_pipe(dev_priv, pch_transcoder) {
> + struct intel_crtc *crtc =
> + 
> to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pch_transcoder]);
> +
> + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> + continue;
>  
>   if (crtc->pch_fifo_underrun_disabled)
>   return false;
> @@ -206,6 +216,9 @@ static void cpt_check_pch_fifo_underruns(struct 
> intel_crtc *crtc)
>  
>   assert_spin_locked(_priv->irq_lock);
>  
> + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> + return;
> +
>   if ((serr_int & SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder)) == 0)
>   return;
>  
> @@ -222,6 +235,9 @@ static void cpt_set_fifo_underrun_reporting(struct 
> drm_device *dev,
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> + if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
> + return;
> +
>   if (enable) {
>   I915_WRITE(SERR_INT,
>  SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
> -- 
> 2.4.10

-- 
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 04/12] drm/i915: Remove double wait_for_vblank on broadwell.

[Ander Conselvan De Oliveira]

On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> wait_vblank is already set in intel_plane_atomic_calc_changes
> for broadwell, waiting for a double vblank is overkill.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Ander Conselvan de Oliveira 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5345ffcce51e..60f17bc5f0ce 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4657,14 +4657,6 @@ intel_post_enable_primary(struct drm_crtc *crtc)
>   int pipe = intel_crtc->pipe;
>  
>   /*
> -  * BDW signals flip done immediately if the plane
> -  * is disabled, even if the plane enable is already
> -  * armed to occur at the next vblank :(
> -  */
> - if (IS_BROADWELL(dev))
> - intel_wait_for_vblank(dev, pipe);
> -
> - /*
>* FIXME IPS should be fine as long as one plane is
>* enabled, but in practice it seems to have problems
>* when going from primary only to sprite only and vice
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request

[Daniel Vetter]

On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote:
> > > Instead of querying the reset counter before every access to the ring,
> > > query it the first time we touch the ring, and do a final compare when
> > > submitting the request. For correctness, we need to then sanitize how
> > > the reset_counter is incremented to prevent broken submission and
> > > waiting across resets, in the process fixing the persistent -EIO we
> > > still see today on failed waits.
> > 
> > tbh that explanation went straight over my head. Questions:
> > - Where do we wait again over a reset? With all the wakeups we should
> >   catch them properly. I guess this needs the detailed scenario to help me
> >   out, since I have dim memories that there is something wrong ;-)
> 
> TDR. In the future (and in past speculative patches) we have proposed
> keeping requests over a reset and requeuing them. That is a complication
> to the simplification of bailing out from the wait. What I have in mind,
> is the recovery code has to fix up the request list somehow, though that
> will be fun.

But even with requeueing the waiters need to bail out and restart the
ioctl. So I don't see why requeueing of requests matter.

And my question was about what exactly is broken when waiting over a
reset? As long as we detect the reset and restart the ioctl we should pick
up any kinds of state fixups the reset work has done and recover
perfectly. Irrespective of whether the reset work has requeued some of the
requests or not.

> > - What precisely is the effect for waiters? I only see moving the
> >   atomic_inc under the dev->struct_mutex, which shouldn't do a hole lot
> >   for anyone. Plus not returning -EAGAIN when reset_in_progress, which
> >   looks like it might result in missed wakeups and deadlocks with the
> >   reset work.
> 
> At the moment, I can trivially wedge the machine. This patch fixes that.
> The patch also ensures that we cannot raise unhandled errors from
> wait-request (EIO/EAGAIN handling has to be explicitly added to the
> caller).

Hm, how/where do we wedge the machine, and how does the fix work?

> The wait-request interface still has the wait-seqno legacy of having to
> acquire the reset_counter under the mutex before calling. That is quite
> hairy and causes a major complication later where we want to amalgamate
> waiters.

Yeah, that's a sensible change. But since I don't yet understand where
exactly the current logic results in a wedge gpu I can't convince myself
that the new one is ok.

> Re EAGAIN. No, it cannot result in missed wakeups since that is internal
> to the wait_request function, nor can it result in new deadlocks with the
> reset worker.

Yeah I think today with just struct_mutex it's impossible. But if we have
more locks the waiting thread could continue to grab more locks instead of
bailing out straight. And then the reset handler would be somewhat screwed
since it isn't guaranteed to make forward progress.

> > I /thought/ that the -EIO is from check_wedge in intel_ring_begin, but
> > that part seems essentially unchanged.
> 
> For two reasons, we need to to protect the access to the ring, and you
> argued that (reporting of EIO from previous wedged GPUs) it was part of
> the ABI. The other ABI that I think is important, is the reporting of
> EIO if the user explicits waits on a request and it is incomplete (i.e.
> wait_ioctl).

Well then I don't get where the -EIO is from. That leaves a truly wedge
gpu as the cause, and for that case I don't get how it can happen by
accident with the current code.
 
> > Aside from all that, shuffling the atomic_inc (if I can convince myself
> > that it's safe) to avoid the reload_in_reset hack looks like a good
> > improvement.
> 
> That's what I said at the time :-p
>  
> > More confused comments below.
> 
> A large proportion of the actual patch is spent trying to make using the
> atomic reset_counter safer (wrt to it changing values between multiple
> tests and subsequent action).
> 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index d83f35c8df34..107711ec956f 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -4415,7 +4415,7 @@ i915_wedged_get(void *data, u64 *val)
> > >   struct drm_device *dev = data;
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > >  
> > > - *val = atomic_read(_priv->gpu_error.reset_counter);
> > > + *val = i915_terminally_wedged(_priv->gpu_error);
> > 
> > Don't we have a few tests left that look at this still?
> 
> One. I strongly believe that the debug interface should not be reporting
> the reset_counter but the wedged status (as that is what it is called).

And that one only writes, so we're perfectly fine I think.

> > > diff --git 

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Calculate watermark related members in the crtc_state, v3.

[Ander Conselvan De Oliveira]

On Tue, 2015-11-24 at 15:55 +0100, Maarten Lankhorst wrote:
> Op 24-11-15 om 15:03 schreef Ander Conselvan De Oliveira:
> > On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> > > This removes pre/post_wm_update from intel_crtc->atomic, and
> > > creates atomic state for it in intel_crtc.
> > > 
> > > Changes since v1:
> > > - Rebase on top of wm changes.
> > > Changes since v2:
> > > - Split disable_cxsr into a separate patch.
> > > 
> > > Signed-off-by: Maarten Lankhorst 
> > > ---
> > >  drivers/gpu/drm/i915/intel_atomic.c  |  1 +
> > >  drivers/gpu/drm/i915/intel_display.c | 31 +--
> > >  drivers/gpu/drm/i915/intel_drv.h |  2 +-
> > >  3 files changed, 15 insertions(+), 19 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > > b/drivers/gpu/drm/i915/intel_atomic.c
> > > index 9f0638a37b6d..4625f8a9ba12 100644
> > > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > > @@ -96,6 +96,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> > >   crtc_state->update_pipe = false;
> > >   crtc_state->disable_lp_wm = false;
> > >   crtc_state->disable_cxsr = false;
> > > + crtc_state->wm_changed = false;
> > >  
> > >   return _state->base;
> > >  }
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 5ee64e67ad8a..db4995406277 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4741,6 +4741,8 @@ intel_pre_disable_primary(struct drm_crtc *crtc)
> > >  static void intel_post_plane_update(struct intel_crtc *crtc)
> > >  {
> > >   struct intel_crtc_atomic_commit *atomic = >atomic;
> > > + struct intel_crtc_state *pipe_config =
> > > + to_intel_crtc_state(crtc->base.state);
> > >   struct drm_device *dev = crtc->base.dev;
> > >   struct drm_i915_private *dev_priv = dev->dev_private;
> > >  
> > > @@ -4751,7 +4753,7 @@ static void intel_post_plane_update(struct
> > > intel_crtc
> > > *crtc)
> > >  
> > >   crtc->wm.cxsr_allowed = true;
> > >  
> > > - if (crtc->atomic.update_wm_post)
> > > + if (pipe_config->wm_changed)
> > >   intel_update_watermarks(>base);
> > This adds an extra call to intel_update_watermarks() for the case where
> > previously update_wm_pre would be set. This won't cause extra register
> > writes
> > because of the dirty check, but I think it deserves a note in the commit
> > message.
> I think intel_update_watermarks needs to be fixed to take a crtc_state and
> whether pre/post commit is used.
> 
> It looks to me like doing anything else could bug if watermarks are changed
> with 1 plane becoming visible and the other invisible..
> > >  
> > >   if (atomic->update_fbc)
> > > @@ -4784,6 +4786,9 @@ static void intel_pre_plane_update(struct intel_crtc
> > > *crtc)
> > >   crtc->wm.cxsr_allowed = false;
> > >   intel_set_memory_cxsr(dev_priv, false);
> > >   }
> > > +
> > > + if (!needs_modeset(_config->base) && pipe_config
> > > ->wm_changed)
> > > + intel_update_watermarks(>base);
> > >  }
> > >  
> > >  static void intel_crtc_disable_planes(struct drm_crtc *crtc, unsigned
> > > plane_mask)
> > > @@ -11706,25 +11711,18 @@ int intel_plane_atomic_calc_changes(struct
> > > drm_crtc_state *crtc_state,
> > >plane->base.id, was_visible, visible,
> > >turn_off, turn_on, mode_changed);
> > >  
> > > - if (turn_on) {
> > > - intel_crtc->atomic.update_wm_pre = true;
> > > - /* must disable cxsr around plane enable/disable */
> > > - if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> > > - pipe_config->disable_cxsr = true;
> > > - /* to potentially re-enable cxsr */
> > > - intel_crtc->atomic.wait_vblank = true;
> > > - intel_crtc->atomic.update_wm_post = true;
> > > - }
> > > - } else if (turn_off) {
> > > - intel_crtc->atomic.update_wm_post = true;
> > > + if (turn_on || turn_off) {
> > > + pipe_config->wm_changed = true;
> > > +
> > >   /* must disable cxsr around plane enable/disable */
> > >   if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> > >   if (is_crtc_enabled)
> > >   intel_crtc->atomic.wait_vblank = true;
> > >   pipe_config->disable_cxsr = true;
> > >   }
> > > - } else if (intel_wm_need_update(plane, plane_state)) {
> > > - intel_crtc->atomic.update_wm_pre = true;
> > > + } else if ((was_visible || visible) &&
> > So this avoids watermark changes when the plane is not visible before or
> > after
> > the update. Wouldn't it be better to fix intel_wm_need_update() instead if
> > returns true in that case?
> 
> If visible is changed wm_changed = true is always set. It would go through the
> (turn_on || turn_off) case.
> 
> I guess checking was_visible || 

Re: [Intel-gfx] [RFC PATCH] drm/i915: fix potential dangling else problems in for_each_ macros

[Daniel Vetter]

On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote:
> > >  /* Iterate over initialised rings */
> > >  #define for_each_ring(ring__, dev_priv__, i__) \
> > >   for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
> > > - if (((ring__) = &(dev_priv__)->ring[(i__)]), 
> > > intel_ring_initialized((ring__)))
> > > + for_each_if ring__) = &(dev_priv__)->ring[(i__)]), 
> > > intel_ring_initialized((ring__
> > 
> > Idly wondering if we would be happy with
> > 
> > for_each_ring(ring__, dev_priv__)
> > for ((ring__) = &(dev_priv__)->ring[0];
> >  (ring__) <= &(dev_priv__)->ring[I915_NUM_RINGS];
> >  (ring__)++)
> >  for_each_if(intel_ring_initialized(ring__))
> > 
> > ?
> > 
> > The downside is that we have used i__ in several places rather than
> > ring->id.
> 
> Fwiw, 13 files changed, 113 insertions(+), 140 deletions(-)
> 
> Seems a reasonable shrinkage.

Maybe for_each_engine even, and phase out for_each_ring completely?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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/12] drm/i915/skl: Update watermarks before the crtc is disabled.

[Ander Conselvan De Oliveira]

On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> On skylake some of the registers are only writable when the correct
> power wells are enabled. Because of this watermarks have to be updated
> before the crtc turns off, or you get unclaimed register read and write
> warnings.
> 
> This patch needs to be modified slightly to apply to -fixes.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92181
> Signed-off-by: Maarten Lankhorst 
> Cc: sta...@vger.kernel.org
> Cc: Matt Roper 

Reviewed-by: Ander Conselvan de Oliveira 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index db4995406277..5345ffcce51e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4753,7 +4753,7 @@ static void intel_post_plane_update(struct intel_crtc
> *crtc)
>  
>   crtc->wm.cxsr_allowed = true;
>  
> - if (pipe_config->wm_changed)
> + if (pipe_config->wm_changed && pipe_config->base.active)
>   intel_update_watermarks(>base);
>  
>   if (atomic->update_fbc)
> @@ -13362,6 +13362,9 @@ static int intel_atomic_commit(struct drm_device *dev,
>   dev_priv->display.crtc_disable(crtc);
>   intel_crtc->active = false;
>   intel_disable_shared_dpll(intel_crtc);
> +
> + if (!crtc->state->active)
> + intel_update_watermarks(crtc);
>   }
>   }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Ditch drm_can_sleep check in wait_for

[Daniel Vetter]

It's causing endless amounts of trouble by hiding pretty serious bugs
where we wait for a few msecs, but accidentally while holding a
spinlock (sometimes even an irqsafe one).

And the only reason for this was to make the mode for the panic
handler work somewhat. But that _really_ needs to be done at a higher
level, since all our sideband mutexes and other stuff isn't covered
with this either.

And the final straw: At least with the current drm infrastructure
we've given up on special panic handlers a while ago:

commit 6066677cfd9d73734ab678b9d14013c860f0f732
Author: Dave Airlie 
Date:   Thu Jul 9 13:15:34 2015 +1000

drm/fb: drop panic handling

So let's just rip this out.

Cc: Mika Kuoppala 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_drv.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ab5c147fa9e9..18d257898a78 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -54,7 +54,7 @@
ret__ = -ETIMEDOUT; \
break;  \
}   \
-   if ((W) && drm_can_sleep()) {   \
+   if (W) {\
usleep_range((W)*1000, (W)*2000);   \
} else {\
cpu_relax();\
-- 
2.5.1

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: fix potential dangling else problems in for_each_ macros

[Daniel Vetter]

On Tue, Nov 24, 2015 at 09:21:56PM +0200, Jani Nikula wrote:
> We have serious dangling else bugs waiting to happen in our for_each_
> style macros with ifs. Consider, for example,
> 
>  #define for_each_power_domain(domain, mask) \
>  for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
>  if ((1 << (domain)) & (mask))
> 
> If this is used in context:
> 
>   if (condition)
>   for_each_power_domain(domain, mask);
>   else
>   foo();
> 
> foo() will be called for each domain *not* in mask, if condition holds,
> and not at all if condition doesn't hold.
> 
> Fix this by reversing the conditions in the macros, and adding an else
> branch for the "for each" block, so that other if/else blocks can't
> interfere. Provide a "for_each_if" helper macro to make it easier to get
> this right.
> 
> v2: move for_each_if to drmP.h in a separate patch.
> 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Jani Nikula 

Both applied to drm-misc, thanks for respinning with drm headers included.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 12 ++--
>  drivers/gpu/drm/i915/intel_display.c|  2 +-
>  drivers/gpu/drm/i915/intel_dsi.h|  2 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  4 ++--
>  4 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3d8741eff7d3..11ae5a5a0a2e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -286,7 +286,7 @@ struct i915_hotplug {
>   list_for_each_entry(intel_plane,\
>   &(dev)->mode_config.plane_list, \
>   base.head)  \
> - if ((intel_plane)->pipe == (intel_crtc)->pipe)
> + for_each_if ((intel_plane)->pipe == (intel_crtc)->pipe)
>  
>  #define for_each_intel_crtc(dev, intel_crtc) \
>   list_for_each_entry(intel_crtc, >mode_config.crtc_list, base.head)
> @@ -303,15 +303,15 @@ struct i915_hotplug {
>  
>  #define for_each_encoder_on_crtc(dev, __crtc, intel_encoder) \
>   list_for_each_entry((intel_encoder), &(dev)->mode_config.encoder_list, 
> base.head) \
> - if ((intel_encoder)->base.crtc == (__crtc))
> + for_each_if ((intel_encoder)->base.crtc == (__crtc))
>  
>  #define for_each_connector_on_encoder(dev, __encoder, intel_connector) \
>   list_for_each_entry((intel_connector), 
> &(dev)->mode_config.connector_list, base.head) \
> - if ((intel_connector)->base.encoder == (__encoder))
> + for_each_if ((intel_connector)->base.encoder == (__encoder))
>  
>  #define for_each_power_domain(domain, mask)  \
>   for ((domain) = 0; (domain) < POWER_DOMAIN_NUM; (domain)++) \
> - if ((1 << (domain)) & (mask))
> + for_each_if ((1 << (domain)) & (mask))
>  
>  struct drm_i915_private;
>  struct i915_mm_struct;
> @@ -730,7 +730,7 @@ struct intel_uncore {
>   for ((i__) = 0, (domain__) = &(dev_priv__)->uncore.fw_domain[0]; \
>(i__) < FW_DOMAIN_ID_COUNT; \
>(i__)++, (domain__) = &(dev_priv__)->uncore.fw_domain[i__]) \
> - if (((mask__) & (dev_priv__)->uncore.fw_domains) & (1 << (i__)))
> + for_each_if (((mask__) & (dev_priv__)->uncore.fw_domains) & (1 
> << (i__)))
>  
>  #define for_each_fw_domain(domain__, dev_priv__, i__) \
>   for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
> @@ -1969,7 +1969,7 @@ static inline struct drm_i915_private 
> *guc_to_i915(struct intel_guc *guc)
>  /* Iterate over initialised rings */
>  #define for_each_ring(ring__, dev_priv__, i__) \
>   for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
> - if (((ring__) = &(dev_priv__)->ring[(i__)]), 
> intel_ring_initialized((ring__)))
> + for_each_if ring__) = &(dev_priv__)->ring[(i__)]), 
> intel_ring_initialized((ring__
>  
>  enum hdmi_force_audio {
>   HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 75f03e5bee51..4b21d5e137dc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12417,7 +12417,7 @@ static bool intel_fuzzy_clock_check(int clock1, int 
> clock2)
>   list_for_each_entry((intel_crtc), \
>   &(dev)->mode_config.crtc_list, \
>   base.head) \
> - if (mask & (1 <<(intel_crtc)->pipe))
> + for_each_if (mask & (1 <<(intel_crtc)->pipe))
>  
>  static bool
>  intel_compare_m_n(unsigned int m, unsigned int n,
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h 
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 

[Intel-gfx] [i-g-t PATCH] scripts: remove display_debug.sh as obsolete

[Jani Nikula]

The script uses the obsoleted and removed intel_reg_read tool. Rather
than mechanically fix this to use intel_reg, observe that the hardcoded
register offsets are platform specific. A quick glance suggests they are
for PCH split platforms with FDI, and as such useful only on a minority
of platforms. Remove the script as obsolete.

If the need for such a script arises, it should be based around using
'intel_reg dump' with display-only register spec files.

Signed-off-by: Jani Nikula 
---
 scripts/display_debug.sh | 172 ---
 1 file changed, 172 deletions(-)
 delete mode 100755 scripts/display_debug.sh

diff --git a/scripts/display_debug.sh b/scripts/display_debug.sh
deleted file mode 100755
index f854f90b846c..
--- a/scripts/display_debug.sh
+++ /dev/null
@@ -1,172 +0,0 @@
-#!/bin/bash
-
-# FBC_CFB_BASE 0x43200
-../tools/intel_reg_read 0x43200
-# FBC_CTL 0x43208
-../tools/intel_reg_read 0x43208
-# ERR_INT 0x44040
-../tools/intel_reg_read 0x44040
-# DE_RRMR 0x44050
-../tools/intel_reg_read 0x44050
-# ARB_CTL 0x45000
-../tools/intel_reg_read 0x45000
-# ARB_CTL2 0x45004
-../tools/intel_reg_read 0x45004
-# MSG_CTL 0x45010
-../tools/intel_reg_read 0x45010
-# Watermarks
-../tools/intel_reg_read 0x45100
-../tools/intel_reg_read 0x45104
-../tools/intel_reg_read 0x45200
-../tools/intel_reg_read 0x45108
-../tools/intel_reg_read 0x4510C
-../tools/intel_reg_read 0x45110
-../tools/intel_reg_read 0x45120
-../tools/intel_reg_read 0x45124
-../tools/intel_reg_read 0x45128
-# Pipe A timing 0x6-0x6004C
-../tools/intel_reg_read 0x6 -c 0x13;
-# Pipe B timing 0x61000-0x6104C
-../tools/intel_reg_read 0x61000 -c 0x13;
-# Pipe C timing 0x62000-0x6204C
-../tools/intel_reg_read 0x62000 -c 0x13;
-# FDI A 0x60100
-# FDI B 0x61100
-# FDI C 0x62100
-# EDP 0x64000
-../tools/intel_reg_read 0x60100
-../tools/intel_reg_read 0x61100
-../tools/intel_reg_read 0x62100
-../tools/intel_reg_read 0x64000
-# Panel fitter A window size 0x68074
-# Panel fitter A control 0x68080
-../tools/intel_reg_read 0x68074
-../tools/intel_reg_read 0x68080
-# Panel fitter B window size 0x68874
-# Panel fitter B control 0x68880
-../tools/intel_reg_read 0x68874
-../tools/intel_reg_read 0x68880
-# Panel fitter C window size 0x69074
-# Panel fitter C control 0x69080
-../tools/intel_reg_read 0x69074
-../tools/intel_reg_read 0x69080
-# Pipe A config 0x70008
-# Pipe B config 0x71008
-# Pipe C config 0x72008
-../tools/intel_reg_read 0x70008
-../tools/intel_reg_read 0x71008
-../tools/intel_reg_read 0x72008
-# Cursor A control 0x70080
-# Cursor B control 0x71080
-# Cursor C control 0x72080
-../tools/intel_reg_read 0x70080
-../tools/intel_reg_read 0x71080
-../tools/intel_reg_read 0x72080
-# Primary A control 0x70180
-# Primary B control 0x71180
-# Primary C control 0x72180
-../tools/intel_reg_read 0x70180
-../tools/intel_reg_read 0x71180
-../tools/intel_reg_read 0x72180
-# Sprite A control 0x70280
-# Sprite B control 0x71280
-# Sprite C control 0x72280
-../tools/intel_reg_read 0x70280
-../tools/intel_reg_read 0x71280
-../tools/intel_reg_read 0x72280
-# Sprite A size 0x70290
-# Sprite B size 0x71290
-# Sprite C size 0x72290
-../tools/intel_reg_read 0x70290
-../tools/intel_reg_read 0x71290
-../tools/intel_reg_read 0x72290
-# Sprite A scaling 0x70304
-# Sprite B scaling 0x71304
-# Sprite C scaling 0x72304
-../tools/intel_reg_read 0x70304
-../tools/intel_reg_read 0x71304
-../tools/intel_reg_read 0x72304
-# PCH DE Interrupt enable 0xC400C
-../tools/intel_reg_read 0xC400C
-# PCH DE Interrupt IIR 0xC4008
-../tools/intel_reg_read 0xC4008
-# PCH DE hotplug 0xC4030
-../tools/intel_reg_read 0xC4030
-# SERR_INT 0xC4040
-../tools/intel_reg_read 0xC4040
-# PCH DPLL A CTL 0xC6014
-# PCH DPLL A Divisor 0 0xC6040
-# PCH DPLL A Divisor 1 0xC6044
-../tools/intel_reg_read 0xC6014
-../tools/intel_reg_read 0xC6040
-../tools/intel_reg_read 0xC6044
-# PCH DPLL B CTL 0xC6018
-# PCH DPLL B Divisor 0 0xC6048
-# PCH DPLL B Divisor 1 0xC604C
-../tools/intel_reg_read 0xC6018
-../tools/intel_reg_read 0xC6048
-../tools/intel_reg_read 0xC604C
-# PCH DPLL DREF CTL 0xC6200
-../tools/intel_reg_read 0xC6200
-# PCH DPLL SEL 0xC7000
-../tools/intel_reg_read 0xC7000
-# PCH Panel Status 0xC7200
-../tools/intel_reg_read 0xC7200
-# PCH Panel Control 0xC7204
-../tools/intel_reg_read 0xC7204
-# Transcoder A timing 0xE-0xE004F
-# Transcoder B timing 0xE1000-0xE104F
-# Transcoder C timing 0xE2000-0xE204F
-../tools/intel_reg_read 0xE -c 0x14;
-../tools/intel_reg_read 0xE1000 -c 0x14;
-../tools/intel_reg_read 0xE2000 -c 0x14;
-# Transcoder A DP CTL 0xE0300
-# Transcoder B DP CTL 0xE1300
-# Transcoder C DP CTL 0xE2300
-../tools/intel_reg_read 0xE0300
-../tools/intel_reg_read 0xE1300
-../tools/intel_reg_read 0xE2300
-# CRT DAC CTL 0xE1100
-../tools/intel_reg_read 0xE1100
-# HDMI/DVI B CTL 0xE1140
-# HDMI/DVI C CTL 0xE1150
-# HDMI/DVI D CTL 0xE1160
-../tools/intel_reg_read 0xE1140
-../tools/intel_reg_read 0xE1150

Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a fw content lost issue after it is evicted

[Chris Wilson]

On Wed, Nov 25, 2015 at 09:40:45AM +0100, Daniel Vetter wrote:
> Hm it's not just batches but any object with relocs. Could this explain
> the oddball libva/uxa hang? Stuff like "after playing $game for hours my
> desktop looked funny", but not for tiling issues.

Possible, but with libva having its own issues with not marking GPU
writes, only time will tell. I say batches because in modern code, only
the batch has the reloc. In UXA and mesa, even the auxiliary buffers with
the relocs are reallocated with each batch.

There's only one swap related corruption issue on gen4, for which we
also know the machine had bad swizzle detection, and there is another
swap related bug on gen2, but neither are actually susceptible to this
bug. I don't have any strong candidates for an eureka moment.
-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] [RFC PATCH] drm/i915: fix potential dangling else problems in for_each_ macros

[Jani Nikula]

On Wed, 25 Nov 2015, Chris Wilson  wrote:
> On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
>> On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote:
>> >  /* Iterate over initialised rings */
>> >  #define for_each_ring(ring__, dev_priv__, i__) \
>> >for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
>> > -  if (((ring__) = &(dev_priv__)->ring[(i__)]), 
>> > intel_ring_initialized((ring__)))
>> > +  for_each_if ring__) = &(dev_priv__)->ring[(i__)]), 
>> > intel_ring_initialized((ring__
>> 
>> Idly wondering if we would be happy with
>> 
>> for_each_ring(ring__, dev_priv__)
>>  for ((ring__) = &(dev_priv__)->ring[0];
>>   (ring__) <= &(dev_priv__)->ring[I915_NUM_RINGS];
>>   (ring__)++)
>>   for_each_if(intel_ring_initialized(ring__))
>> 
>> ?
>> 
>> The downside is that we have used i__ in several places rather than
>> ring->id.
>
> Fwiw, 13 files changed, 113 insertions(+), 140 deletions(-)

Seems good, looks like you have the patch so I won't bother. v2 of my
patch was merged to drm-misc now, so that complicates a bit. Perhaps the
i__ to ring->id change could be a prep step. *shrug*.

BR,
Jani.



>
> Seems a reasonable shrinkage.
> -Chris

-- 
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 : Avoid superfluous invalidation of CPU cache lines

[Daniel Vetter]

On Wed, Nov 25, 2015 at 02:57:47PM +0530, Goel, Akash wrote:
> 
> 
> On 11/25/2015 2:51 PM, Daniel Vetter wrote:
> >On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> >>On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> >>>On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> >From: Akash Goel 
> >
> >When the object is moved out of CPU read domain, the cachelines
> >are not invalidated immediately. The invalidation is deferred till
> >next time the object is brought back into CPU read domain.
> >But the invalidation is done unconditionally, i.e. even for the case
> >where the cachelines were flushed previously, when the object moved out
> >of CPU write domain. This is avoidable and would lead to some 
> >optimization.
> >Though this is not a hypothetical case, but is unlikely to occur often.
> >The aim is to detect changes to the backing storage whilst the
> >data is potentially in the CPU cache, and only clflush in those case.
> >
> >Signed-off-by: Chris Wilson 
> >Signed-off-by: Akash Goel 
> >---
> >  drivers/gpu/drm/i915/i915_drv.h | 1 +
> >  drivers/gpu/drm/i915/i915_gem.c | 9 -
> >  2 files changed, 9 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index df9316f..fedb71d 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> > unsigned long gt_ro:1;
> > unsigned int cache_level:3;
> > unsigned int cache_dirty:1;
> >+unsigned int cache_clean:1;
> 
> So now we have cache_dirty and cache_clean which seems redundant,
> except somehow cache_dirty != !cache_clean?
> >>
> >>Exactly, not entirely redundant. I did think something along MESI lines
> >>would be useful, but that didn't capture the different meanings we
> >>employ.
> >>
> >>cache_dirty tracks whether we have been eliding the clflush.
> >>
> >>cache_clean tracks whether we know the cache has been completely
> >>clflushed.
> >>
> >>(cache_clean implies !cache_dirty, but
> >>!cache_clean does not imply cache_dirty)
> >>
> >>>We also have read_domains & DOMAIN_CPU. Which is which?
> >>
> >>DOMAIN_CPU implies that the object may be in the cpu cache (modulo the
> >>clflush elision above).
> >>
> >>DOMAIN_CPU implies !cache_clean
> >>
> >>and even
> >>
> >>cache_clean implies !DOMAIN_CPU
> >>
> >>but
> >>
> >>!DOMAIN_CPU does not imply cache_clean
> >
> >All the above should be in the kerneldoc (per-struct-member comments
> >please) of drm_i915_gem_object. Akash, can you please amend your patch?
> >And please make sure we do include that kerneldoc somewhere ... might need
> >an upfront patch to do that, for just drm_i915_gem_object.
> 
> I floated the amended patch, earlier today,
> http://lists.freedesktop.org/archives/intel-gfx/2015-November/081194.html.
> Please kindly check that.

Already done and replied here because I think this should be lifted to
kerneldoc for the structure itself. That's why I replied here ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] intel_dp_detect redesign

[Daniel Vetter]

On Tue, Nov 24, 2015 at 08:13:06PM +0100, Daniel Vetter wrote:
> Hi Ander,
> 
> Dave had a short discussion about reprobing DP (and MST) state on
> resume. I think this is something we've missed in our dp hpd handling
> rework thus far. And at least for SST we need to take it into account
> since it would be a regression.
> 
> Currently it's done through ->detect callback from
> drm_helper_hpd_irq_event called from i915_drm_resume. Also irc logs
> below.

Oh and there's an issue for the hdmi hpd changes that have been merged and
reverted too: Those will run into the same problem. Plus in addition doing
nothing in ->detect will break storm handling (since that falls back to
the probe helper poll work).
-Daniel

> 
> Thanks, Daniel
> 
>  danvet: so probing on resume, it seems a bit inconsistent,
> is the kernel driver meant to be doing it?
>  I think since we stopped vt switching we've stopped doing
> it, which is making mst docking kinda suck
>  mst was after stopping vt-switching I thought
>  but yeah we should reprobe
>  and we do (at least occasionally if it's not broken again)
>  well people are just noticing it more with mst
>  but not for mst iirc
>  mst just restores and hopes I think
>  but when you suspend in the dock, and move the laptop, and
> resume things don't work unless you xrandr
>  and vice-versa
>  I looked into it for 5 minutes when tedtso complained an ran ;-)
>  well reproving should bring up/tear down any mst
>  hm, xrandr shouldn't be enough to fix it, we need a real hpd
> to redo the mst stuff I thought ...
>  so I don't think mst is special here
>  we reprobe through probe helpers
>  janesma, Pali, bleh sorry.. yeah, looks like it needs a
> stdbool.h.. not sure why I didn't hit that compile error.. sorry about
> that..
>  all mst stuff is done directly from hpd since it needs to
> know long vs. short
>  so it misses out
>  if we probe a DP port and the device is gone, MST will get torn down
>  danvet: not so
>  unless someone else has been hacking the driver
> * xxmitsu (~m...@5-15-26-95.residential.rdsnet.ro) has joined #dri-devel
>  oh, the completely gone case
> * danvet looks
>  oh maybe we don't handle that properly
>  oh you might be right, I wonder where we should hook that in
>  drm_helper_hpd_irq_event in i915_drm_resume should get this
> right for non-mst
>  well non-DP maybe, anderco and rtshiva are reworking this
>  but it's not merged yet
>  I'm guessing detect should not if a port was in mst
>  and is now disconnected
>  ok, skeleton is there but not all
>  intel_dp_detect
>  drm_dp_mst_topology_mgr_resume should probably check the
> entire hierarchy, not just a simple dpcd write
>  and if anything changes, we need to generate the uevent somewhere
>  so might be better to re-run the entire dp_detect pile
>  tricky part is that we need to lie about long vs. short
>  it should be treated like a long hpd if anything changed,
> short otherwise
>  well we have mgr->cbs->hotplug in the mst manager already
>  so should reuse that hook
>  airlied, I guess just fix up drm_dp_mst_topology_mgr_resume
> to do rescan the entire hierarchy
>  calling ->hotplug if anything changed
>  and only returning true if the sink isn't mst any more
>  along the lines of what intel_dp_probe_mst does
>  it's not going to be all that simple ;-)
>  at least if you care about stuff like laptopt connected to
> dock -> screen
>  s/r
>  doesn't sounds like fun, I'll stick on my list of things to
> be scared off
>  then laptop only connected to dock
>  airlied, done the same
>  well the use case is laptop in dock, suspend, resume with
> laptop plugged into a monitor
>  but the fun part is that anderco/rtshiva want to rework this
>  and if they do they'll also break sst dp ;-)
>  so I think I have some victims
>  airlied, yeah that's step one
>  I'd prefer to get the fixes in before redesigning the tower
>  but that already has all the complexity on the driver side
>  only thing missing is the code in the mst helper to rescan
> the entire tree and call ->hot_plug if needed
>  problem is that current dp hpd handling is a mess already
>  it's hard to fix anything in there atm
>  so fixing this properly is needed anyway
>  it's just that I've forgotten about the resume case for plain
> DP myself ;-)
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
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 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Wed, 25 Nov 2015 10:56:51 +0100,
Zhang, Xiong Y wrote:
> 
> Recently I always see the following error message during S4 or S3 resume with 
> drm-intel-nightly.
> [   97.778063] PM: Syncing filesystems ... done.
> [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done.
> [   97.804297] PM: Marking nosave pages: [mem 0x-0x0fff]
> [   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
> [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
> [   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
> [   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
> [   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
> [   97.804387] PM: Marking nosave pages: [mem 0x8800-0x]
> [   97.806363] PM: Basic memory bitmaps created
> [   97.806409] PM: Preallocating image memory... done (allocated 321557 pages)
> [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 MB/s)
> [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
> done.
> [   98.151998] Suspending console(s) (use no_console_suspend to debug)
> [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI 
> status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> [   99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
> cmd=0x206f2e08
> [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 
> 128
> [  101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout, 
> switching to polling mode: last cmd=0x206f2f00
> [  102.195492] snd_hda_intel :00:1f.3: No response from codec, disabling 
> MSI: last cmd=0x206f2f00
> [  103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout, 
> switching to single_cmd mode: last cmd=0x206f2f00
> [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> 
> The bisect result points to this commit. 
> I checked this patch and had one question: if i915 driver wake up ahead of 
> snd_hda_intel driver during resume,  i915 driver will call audio driver's 
> hdmi_present_sense() function through this patch, but the audio interrupt is 
> disabled at this moment, how could hdmi_present_sense() get the response from 
> codec ?  

Yeah, a bad thing happens there.  The fix should be simple like below,
though.  Basically the pins are checked in the resume callback in
anyway, so there is no need to handle the notification during PM.

Could you check whether it works?


thanks,

Takashi

---
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index bdb6f226d006..b468fe0e6195 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int 
port)
struct hda_codec *codec = audio_ptr;
int pin_nid = port + 0x04;
 
-   check_presence_and_report(codec, pin_nid);
+   /* don't call notifier during PM; will be checked in resume callback */
+   if (!atomic_read(>core.in_pm))
+   check_presence_and_report(codec, pin_nid);
 }
 
 static int patch_generic_hdmi(struct hda_codec *codec)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/12] drm/i915: Rename request->ringbuf to request->ring

[Tvrtko Ursulin]

On 24/11/15 15:25, Chris Wilson wrote:

On Tue, Nov 24, 2015 at 03:08:09PM +, Tvrtko Ursulin wrote:


On 20/11/15 12:43, Chris Wilson wrote:

Now that we have disambuigated ring and engine, we can use the clearer
and more consistent name for the intel_ringbuffer pointer in the
request.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h|   2 +-
  drivers/gpu/drm/i915/i915_gem.c|  28 +++---
  drivers/gpu/drm/i915/i915_gem_context.c|   2 +-
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   4 +-
  drivers/gpu/drm/i915/i915_gem_gtt.c|   6 +-
  drivers/gpu/drm/i915/intel_display.c   |  10 +-
  drivers/gpu/drm/i915/intel_lrc.c   | 149 ++---
  drivers/gpu/drm/i915/intel_mocs.c  |  32 +++
  drivers/gpu/drm/i915/intel_overlay.c   |  42 
  drivers/gpu/drm/i915/intel_ringbuffer.c|  86 -
  10 files changed, 178 insertions(+), 183 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9ce8b3fcb3a0..b7eaa2deb437 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2185,7 +2185,7 @@ struct drm_i915_gem_request {
 * context.
 */
struct intel_context *ctx;
-   struct intel_ringbuffer *ringbuf;
+   struct intel_ringbuffer *ring;


What was the problem with ringbuf? Struct is still called ringbuf
and the files as well after the patch series.


It introduced a major naming clash with existing code. I am trying to
remove the needlessly duplicated interfaces, and restore the historic
naming conventions.


Ok my point was that I am not sure if it is worth renaming things a) 
partially, and b) that ring is a good name for intel_ringbuffer. Ringbuf 
sounds at least just as good, in fact better to me. So this renaming 
feels like unnecessary churn. And the fact you don't even do all of them 
in the patch series just reinforces that.


But as Daniel already approved this it doesn't really matter apart for 
"for the record".


Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects

[Daniel Vetter]

On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote:
> > > If the system has no available swap pages, we cannot make forward
> > > progress in the shrinker by releasing active pages, only by releasing
> > > purgeable pages which are immediately reaped. Take total_swap_pages into
> > > account when counting up available objects to be shrunk and subsequently
> > > shrinking them. By doing so, we avoid unbinding objects that cannot be
> > > shrunk and so wasting CPU cycles flushing those objects from the GPU to
> > > the system and then immediately back again (as they will more than
> > > likely be reused shortly after).
> > > 
> > > Based on a patch by Akash Goel.
> > > 
> > > Reported-by: Akash Goel 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Akash Goel 
> > > Cc: sourab.gu...@intel.com
> > 
> > Cc: linux...@kvack.org should be done on this one, just in case they have
> > ideas for proper interfaces for this. Which might be, given that Jerome
> > Glisse is working on swaput-to-vram and other fun stuff like that.
> > 
> > Also, how does stuff like zswap (or whatever "compress my swap in memory"
> > is called again) factor in here? Iirc Android very much does use that.
> 
> It doesn't. We would need
> 
> #include 
> 
> static bool swap_available(void)
> {
>   return total_swap_pages || frontswap_enabled;
> }
> 
> But if that then returns true for Android it seems the primary usecase
> is invalidated.

Well swapping to frontswap should be ok. Trashing not so much, and if we
do that I suspect there's something really loopsided with memory usage
balancing going on ... Does the android workload have your "only shrink
inactive" patch already?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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 : Avoid superfluous invalidation of CPU cache lines

[Daniel Vetter]

On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> > > > From: Akash Goel 
> > > > 
> > > > When the object is moved out of CPU read domain, the cachelines
> > > > are not invalidated immediately. The invalidation is deferred till
> > > > next time the object is brought back into CPU read domain.
> > > > But the invalidation is done unconditionally, i.e. even for the case
> > > > where the cachelines were flushed previously, when the object moved out
> > > > of CPU write domain. This is avoidable and would lead to some 
> > > > optimization.
> > > > Though this is not a hypothetical case, but is unlikely to occur often.
> > > > The aim is to detect changes to the backing storage whilst the
> > > > data is potentially in the CPU cache, and only clflush in those case.
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Signed-off-by: Akash Goel 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > >  drivers/gpu/drm/i915/i915_gem.c | 9 -
> > > >  2 files changed, 9 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index df9316f..fedb71d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> > > > unsigned long gt_ro:1;
> > > > unsigned int cache_level:3;
> > > > unsigned int cache_dirty:1;
> > > > +   unsigned int cache_clean:1;
> > > 
> > > So now we have cache_dirty and cache_clean which seems redundant,
> > > except somehow cache_dirty != !cache_clean?
> 
> Exactly, not entirely redundant. I did think something along MESI lines
> would be useful, but that didn't capture the different meanings we
> employ.
> 
> cache_dirty tracks whether we have been eliding the clflush.
> 
> cache_clean tracks whether we know the cache has been completely
> clflushed.
> 
> (cache_clean implies !cache_dirty, but
> !cache_clean does not imply cache_dirty)
> 
> > We also have read_domains & DOMAIN_CPU. Which is which?
> 
> DOMAIN_CPU implies that the object may be in the cpu cache (modulo the
> clflush elision above).
> 
> DOMAIN_CPU implies !cache_clean
> 
> and even
> 
> cache_clean implies !DOMAIN_CPU
> 
> but
> 
> !DOMAIN_CPU does not imply cache_clean

All the above should be in the kerneldoc (per-struct-member comments
please) of drm_i915_gem_object. Akash, can you please amend your patch?
And please make sure we do include that kerneldoc somewhere ... might need
an upfront patch to do that, for just drm_i915_gem_object.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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 : Avoid superfluous invalidation of CPU cache lines

[Goel, Akash]

On 11/25/2015 2:51 PM, Daniel Vetter wrote:

On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:

On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:

On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:

On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:

From: Akash Goel 

When the object is moved out of CPU read domain, the cachelines
are not invalidated immediately. The invalidation is deferred till
next time the object is brought back into CPU read domain.
But the invalidation is done unconditionally, i.e. even for the case
where the cachelines were flushed previously, when the object moved out
of CPU write domain. This is avoidable and would lead to some optimization.
Though this is not a hypothetical case, but is unlikely to occur often.
The aim is to detect changes to the backing storage whilst the
data is potentially in the CPU cache, and only clflush in those case.

Signed-off-by: Chris Wilson 
Signed-off-by: Akash Goel 
---
  drivers/gpu/drm/i915/i915_drv.h | 1 +
  drivers/gpu/drm/i915/i915_gem.c | 9 -
  2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index df9316f..fedb71d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
unsigned long gt_ro:1;
unsigned int cache_level:3;
unsigned int cache_dirty:1;
+   unsigned int cache_clean:1;


So now we have cache_dirty and cache_clean which seems redundant,
except somehow cache_dirty != !cache_clean?


Exactly, not entirely redundant. I did think something along MESI lines
would be useful, but that didn't capture the different meanings we
employ.

cache_dirty tracks whether we have been eliding the clflush.

cache_clean tracks whether we know the cache has been completely
clflushed.

(cache_clean implies !cache_dirty, but
!cache_clean does not imply cache_dirty)


We also have read_domains & DOMAIN_CPU. Which is which?


DOMAIN_CPU implies that the object may be in the cpu cache (modulo the
clflush elision above).

DOMAIN_CPU implies !cache_clean

and even

cache_clean implies !DOMAIN_CPU

but

!DOMAIN_CPU does not imply cache_clean


All the above should be in the kerneldoc (per-struct-member comments
please) of drm_i915_gem_object. Akash, can you please amend your patch?
And please make sure we do include that kerneldoc somewhere ... might need
an upfront patch to do that, for just drm_i915_gem_object.


I floated the amended patch, earlier today,
http://lists.freedesktop.org/archives/intel-gfx/2015-November/081194.html.
Please kindly check that.

Best regards
Akash



-Daniel


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

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

Recently I always see the following error message during S4 or S3 resume with 
drm-intel-nightly.
[   97.778063] PM: Syncing filesystems ... done.
[   97.801550] Freezing user space processes ... (elapsed 0.002 seconds) done.
[   97.804297] PM: Marking nosave pages: [mem 0x-0x0fff]
[   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
[   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
[   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
[   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
[   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
[   97.804387] PM: Marking nosave pages: [mem 0x8800-0x]
[   97.806363] PM: Basic memory bitmaps created
[   97.806409] PM: Preallocating image memory... done (allocated 321557 pages)
[   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02 MB/s)
[   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[   98.151998] Suspending console(s) (use no_console_suspend to debug)
[   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2: HDMI status: 
Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
[   99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last 
cmd=0x206f2e08
[   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0, force 
128
[  101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout, switching 
to polling mode: last cmd=0x206f2f00
[  102.195492] snd_hda_intel :00:1f.3: No response from codec, disabling 
MSI: last cmd=0x206f2f00
[  103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout, switching 
to single_cmd mode: last cmd=0x206f2f00
[  103.201396] azx_single_wait_for_response: 42 callbacks suppressed

The bisect result points to this commit. 
I checked this patch and had one question: if i915 driver wake up ahead of 
snd_hda_intel driver during resume,  i915 driver will call audio driver's 
hdmi_present_sense() function through this patch, but the audio interrupt is 
disabled at this moment, how could hdmi_present_sense() get the response from 
codec ?  

thanks
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> David Henningsson
> Sent: Saturday, August 29, 2015 1:03 AM
> To: ti...@suse.de; alsa-de...@alsa-project.org;
> intel-gfx@lists.freedesktop.org; jani.nik...@linux.intel.com; Yang, Libin; 
> Vetter,
> Daniel
> Cc: David Henningsson
> Subject: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD 
> notify
> events
> 
> Whenever there is an event from the i915 driver, wake the codec
> and recheck plug/unplug + ELD status.
> 
> This fixes the issue with lost unsol events in power save mode,
> the codec and controller can now sleep in D3 and still know when
> the HDMI monitor has been connected.
> 
> Right now, this might mean we get two callbacks from the same event,
> one from the unsol event and one from the i915 driver, but this is
> not harmful and can be optimised away in a later patch.
> 
> Reviewed-by: Takashi Iwai 
> Signed-off-by: David Henningsson 
> ---
>  sound/pci/hda/patch_hdmi.c | 22 +-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index a97db5f..acbfbe0 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -37,6 +37,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include "hda_codec.h"
>  #include "hda_local.h"
>  #include "hda_jack.h"
> @@ -144,6 +146,9 @@ struct hdmi_spec {
>*/
>   struct hda_multi_out multiout;
>   struct hda_pcm_stream pcm_playback;
> +
> + /* i915/powerwell (Haswell+/Valleyview+) specific */
> + struct i915_audio_component_audio_ops i915_audio_ops;
>  };
> 
> 
> @@ -2191,6 +2196,9 @@ static void generic_hdmi_free(struct hda_codec
> *codec)
>   struct hdmi_spec *spec = codec->spec;
>   int pin_idx;
> 
> + if (is_haswell_plus(codec) || is_valleyview_plus(codec))
> + 

Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects

[Chris Wilson]

On Wed, Nov 25, 2015 at 10:17:49AM +0100, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote:
> > > > If the system has no available swap pages, we cannot make forward
> > > > progress in the shrinker by releasing active pages, only by releasing
> > > > purgeable pages which are immediately reaped. Take total_swap_pages into
> > > > account when counting up available objects to be shrunk and subsequently
> > > > shrinking them. By doing so, we avoid unbinding objects that cannot be
> > > > shrunk and so wasting CPU cycles flushing those objects from the GPU to
> > > > the system and then immediately back again (as they will more than
> > > > likely be reused shortly after).
> > > > 
> > > > Based on a patch by Akash Goel.
> > > > 
> > > > Reported-by: Akash Goel 
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Akash Goel 
> > > > Cc: sourab.gu...@intel.com
> > > 
> > > Cc: linux...@kvack.org should be done on this one, just in case they have
> > > ideas for proper interfaces for this. Which might be, given that Jerome
> > > Glisse is working on swaput-to-vram and other fun stuff like that.
> > > 
> > > Also, how does stuff like zswap (or whatever "compress my swap in memory"
> > > is called again) factor in here? Iirc Android very much does use that.
> > 
> > It doesn't. We would need
> > 
> > #include 
> > 
> > static bool swap_available(void)
> > {
> > return total_swap_pages || frontswap_enabled;
> > }
> > 
> > But if that then returns true for Android it seems the primary usecase
> > is invalidated.
> 
> Well swapping to frontswap should be ok. Trashing not so much, and if we
> do that I suspect there's something really loopsided with memory usage
> balancing going on ... Does the android workload have your "only shrink
> inactive" patch already?

I'll let Akash or Sourab comment, but the background to the patch was
that they observed that under memory pressure a framebuffer was being
unbound (obviously not pinned as a current scanout) and then rebound
(clflushing both ways ofc). My gut says that the priority lists in the
kernel and userspace are akilter if we either fail to purge the LRU
object in the kernel or if userspace then doesn't try to reuse the MRU
backbuffer. One thing I did notice when also dealing with memory
pressure flushing backbuffers was (a) they were unaligned and so needed
rebinding before pinning
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly=df636036d120c6227d1918cfd6d70232d8d37b4c
and (b) we didn't bump the scanout on the inactive list
http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly=3a23ff3e5e201a52068d6e9d65f4ffb95077c21e
-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 v1] drm/i915/guc: Fix a fw content lost issue after it is evicted

[Daniel Vetter]

On Wed, Nov 25, 2015 at 09:02:20AM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 09:40:45AM +0100, Daniel Vetter wrote:
> > Hm it's not just batches but any object with relocs. Could this explain
> > the oddball libva/uxa hang? Stuff like "after playing $game for hours my
> > desktop looked funny", but not for tiling issues.
> 
> Possible, but with libva having its own issues with not marking GPU
> writes, only time will tell. I say batches because in modern code, only
> the batch has the reloc. In UXA and mesa, even the auxiliary buffers with
> the relocs are reallocated with each batch.

Ah, I didn't realize/forgot that UXA doesn't reuse the indirect state.

> There's only one swap related corruption issue on gen4, for which we
> also know the machine had bad swizzle detection, and there is another
> swap related bug on gen2, but neither are actually susceptible to this
> bug. I don't have any strong candidates for an eureka moment.

Was just a thought really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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: Move VMAs to inactive as request are retired

[Tvrtko Ursulin]

On 24/11/15 17:47, Daniel Vetter wrote:

On Mon, Nov 23, 2015 at 03:12:35PM +, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Current code moves _any_ VMA to the inactive list only when
_all_ rendering on an object (so from any context or VM) has
been completed.

This creates an un-natural situation where the context (and
VM) destructors can run with VMAs still on the respective
active list.

Change here is to move VMAs to the inactive list as the
requests are getting retired.

Signed-off-by: Tvrtko Ursulin 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
Testcase: igt/gem_request_retire/retire-vma-not-inactive
Cc: Daniel Vetter 
Cc: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_gem.c | 17 -
  1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cd7e102720f4..47a743246d2c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2413,17 +2413,32 @@ static void
  i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring)
  {
struct i915_vma *vma;
+   struct i915_address_space *vm;

RQ_BUG_ON(obj->last_read_req[ring] == NULL);
RQ_BUG_ON(!(obj->active & (1 << ring)));

list_del_init(>ring_list[ring]);
-   i915_gem_request_assign(>last_read_req[ring], NULL);

if (obj->last_write_req && obj->last_write_req->ring->id == ring)
i915_gem_object_retire__write(obj);

obj->active &= ~(1 << ring);
+
+   if (obj->last_read_req[ring]->ctx->ppgtt)
+   vm = >last_read_req[ring]->ctx->ppgtt->base;
+   else
+   vm = >last_read_req[ring]->i915->gtt.base;
+
+   list_for_each_entry(vma, >vma_list, vma_link) {
+   if (vma->vm == vm &&
+   vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL &&
+   !list_empty(>mm_list))
+   list_move_tail(>mm_list, >vm->inactive_list);
+   }


This is only a partial solution since with schedulers and semaphores and a
few depencies on a given object, but in different vm you can still end up
with an object that is idle in a vm, but slipped through here.


Could you describe the exact scenario you had in mind? I won't pretend 
it this is simple code and I have it all figured out.



Also, checking for the view type is some strange layering. Why that?


!ppgtt to skip potential other views I thought, no?

Regards,

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

Re: [Intel-gfx] [PATCH 0/4] PSR general improvements and stabilization.

[Daniel Vetter]

On Tue, Nov 24, 2015 at 08:53:43PM +, Vivi, Rodrigo wrote:
> On Tue, 2015-11-24 at 17:12 +, Daniel Stone wrote:
> > Hi Rodrigo,
> > 
> > On 11 November 2015 at 21:19, Rodrigo Vivi  
> > wrote:
> > > Proceeding with the big series split here goes the general PSR
> > > improvements and stabilization work.
> > > 
> > > There is no critical fix on this series although I believe it is
> > > good to have all of them before we can enable PSR back by default.
> > 
> > For the series:
> > Tested-by: Daniel Stone  # SKL
> 
> Thank you very much for this and the aux one. 
> 
> > 
> > I haven't managed to get to BDW yet since that relies on IPS bits.
> 
> Oh, Daniel or Jani reverted the fastboot so PSR is just working well on
> BDW regardless that initialization rework.
> 
> I'm still going to do the encoder fixup that Daniel suggest and accept
> your suggestions on the IPS one, but they shouldn't be blocking any of
> the PSR work anymore.

Yeah, my plan is to re-enable fastboot just in -nightly for better test
coverage. Similar to how we enable psr/fbc and all that stuff in
testcases, for better coverage.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [i-g-t PATCH] tools: fix intel_gpu_abrt to use intel_reg

[Jani Nikula]

intel_reg_dumper is gone, replaced by 'intel_reg dump'.

Signed-off-by: Jani Nikula 
---
 tools/intel_gpu_abrt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/intel_gpu_abrt b/tools/intel_gpu_abrt
index a38137d795f4..bde6fb0d2493 100755
--- a/tools/intel_gpu_abrt
+++ b/tools/intel_gpu_abrt
@@ -55,7 +55,7 @@ get /etc/X11/xorg.conf.d/ X
 dmesg > $tardir/dmesg
 lspci -nn > $tardir/lspci
 
-$igtdir/intel_reg_dumper > $tardir/intel_reg_dumper.txt
+$igtdir/intel_reg dump > $tardir/intel_reg_dump.txt
 $igtdir/intel_bios_dumper $tardir/intel_bios_dump
 $igtdir/intel_stepping > $tardir/intel_stepping
 
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Move wait for GuC out of spinlock/unlock

[Daniel Vetter]

On Tue, Nov 24, 2015 at 02:34:46PM -0800, Yu Dai wrote:
> 
> 
> On 11/24/2015 11:13 AM, Daniel Vetter wrote:
> >On Tue, Nov 24, 2015 at 10:36:54AM -0800, Yu Dai wrote:
> >>
> >>
> >> On 11/24/2015 10:08 AM, Daniel Vetter wrote:
> >> >On Tue, Nov 24, 2015 at 07:05:47PM +0200, Imre Deak wrote:
> >> >> On ti, 2015-11-24 at 09:00 -0800, Yu Dai wrote:
> >> >> >
> >> >> > On 11/24/2015 05:26 AM, Imre Deak wrote:
> >> >> > > On ti, 2015-11-24 at 14:04 +0100, Daniel Vetter wrote:
> >> >> > > > On Mon, Nov 23, 2015 at 03:02:58PM -0800, yu@intel.com wrote:
> >> >> > > > > From: Alex Dai 
> >> >> > > > >
> >> >> > > > > When GuC Work Queue is full, driver will wait GuC for avaliable
> >> >> > > > > space by delaying 1ms. The wait needs to be out of spinlockirq
> >> >> > > > > /
> >> >> > > > > unlock. Otherwise, lockup happens because jiffies won't be
> >> >> > > > > updated
> >> >> > > > > dur to irq is disabled.
> >> >> > > > >
> >> >> > > > > Issue is found in igt/gem_close_race.
> >> >> > > > >
> >> >> > > > > Signed-off-by: Alex Dai 
> >> >> > > > > ---
> >> >> > > > >  drivers/gpu/drm/i915/i915_guc_submission.c | 27
> >> >> > > > > +-
> >> >> > > > > -
> >> >> > > > >  1 file changed, 17 insertions(+), 10 deletions(-)
> >> >> > > > >
> >> >> > > > > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> >> >> > > > > b/drivers/gpu/drm/i915/i915_guc_submission.c
> >> >> > > > > index 0a6b007..1418397 100644
> >> >> > > > > --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >> >> > > > > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >> >> > > > > @@ -201,10 +201,13 @@ static int guc_ring_doorbell(struct
> >> >> > > > > i915_guc_client *gc)
> >> >> > > > > union guc_doorbell_qw *db;
> >> >> > > > > void *base;
> >> >> > > > > int attempt = 2, ret = -EAGAIN;
> >> >> > > > > +   unsigned long flags;
> >> >> > > > >
> >> >> > > > > base = kmap_atomic(i915_gem_object_get_page(gc-
> >> >> > > > > > client_obj, 0));
> >> >> > > >
> >> >> > > > We don't need kmap_atomic anymore here now, since it's outside of
> >> >> > > > the
> >> >> > > > spinlock.
> >> >> > > >
> >> >> > > > > desc = base + gc->proc_desc_offset;
> >> >> > > > >
> >> >> > > > > +   spin_lock_irqsave(>wq_lock, flags);
> >> >> > > >
> >> >> > > > Please don't use the super-generic _irqsave. It's expensive and
> >> >> > > > results in
> >> >> > > > fragile code when someone accidentally reuses something in an
> >> >> > > > interrupt
> >> >> > > > handler that was never meant to run in that context.
> >> >> > > >
> >> >> > > > Instead please use the most specific funtion:
> >> >> > > > - spin_lock if you know you are in irq context.
> >> >> > > > - sipn_lock_irq if you know you are not.
> >> >> > >
> >> >> > > Right, and simply spin_lock() if the lock is not taken in IRQ
> >> >> > > context
> >> >> > > ever.
> >> >> >
> >> >> > This is not in IRQ context. So I will use spin_lock_irq instead.
> >> >>
> >> >> You can just use spin_lock(). spin_lock_irq() makes only sense if you
> >> >> take the lock in IRQ context too, which is not the case.
> >> >
> >> >Imo just drop both spinlocks, adding locks for debugfs is overkill imo.
> >> >
> >> How about using mutex_lock_interruptible(>struct_mutex) instead in
> >> debugfs, which is to replace host2guc lock.
> >
> >Yes.
> >
> >> spinlock during ring the door bell is still needed.
> >
> >Where/why is that needed? At least on a quick look I didn't notice
> >anything.
> >
> 
> Currently there is only one guc client to do the commands submission. It
> appears we don't need the lock. When there are more clients and all write to
> the scratch registers or ring the door bell, we don't want them interact
> with each other. Also, if we implement guc to host interrupt (says to handle
> the log buffer full event), we do need to protect the guc client content.
> Well, none presents today. I can clean up these and test out.

Yeah I think it's better to add locking when we need it, since very likely
something will have changed in the codebase by then. Otherwise there's
only complication and confusion. So please remove the spinlocks and use
the usual interruptible mutex locking for debugfs for now.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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 v1] drm/i915/guc: Fix a fw content lost issue after it is evicted

[Daniel Vetter]

On Tue, Nov 24, 2015 at 11:01:25PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 07:06:21PM +0100, Daniel Vetter wrote:
> > Just setting obj->dirty only works if you also have the pages.
> 
> Exactly. The CPU access has historically always been page-by-page. The
> style here more or less to emulate the CPU mmap.
>  
> > But it's also not awesome that set_to_gtt_domain does this for callers.
> 
> Hmm, do you have an example where we want set-to-gtt(write), but not
> actually write through the backing storage? Internal use of set-to-gtt
> has never been ideal (e.g. context) but we haven't yet come up with a
> better semantic.

Just the inconsistency that Dave pointed out is a bit worrisome. At most
we can fix this with docs (which atm we have), which gives us a rather low
score on API design (still a positive one still it's possible to get
right). I agree that I don't have better semantics either.

> > For lack of clear solutions I'd go with sprinkling obj->dirty or
> > page_set_dirty over callers. Aside: relocate_entry_cpu probably gets away
> > because of the unconditional obj->dirty we do later on, and that we redo
> > all relocs if a fault happens. Still would be good to fix it, just for
> > safety.
> 
> [copy_batch() isn't a bug as the contents are invalidated after use
> anyway]

Just for consistency adding the obj->dirty after get_pages won't hurt
though.

> relocate_entry_cpu() is a bug we never caught. Indeed we've papered over
> it to mask some over userspace issues, but just adding the set_page_dirty()
> as required isn't going to be a big hardship.

Yeah.

> We have tons of swapthrash tests to check persistency of GPU buffers,
> but we never tried to thrash the batches themselves out to swap and then
> reuse them.
> 
> I guess that it is because userspace doesn't reuse batches that we never
> had report of the issue. Hibernating would be a good exercise of such.

Hm it's not just batches but any object with relocs. Could this explain
the oddball libva/uxa hang? Stuff like "after playing $game for hours my
desktop looked funny", but not for tiling issues.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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 01/29] pci: Decouple quirks.c from i915_reg.h

[Bjorn Helgaas]

Hi Ville,

On Wed, Nov 04, 2015 at 11:19:49PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> i915 register defines are going to become type safe, so going forward
> the register defines can't be used as straight numbers. Since quirks.c
> needs just a few extra register defines from i915_reg.h, decouple the
> two by defining the required registers locally in quirks.c. This was
> already done for a few other igpu related registers.
> 
> Cc: Bjorn Helgaas 
> Cc: linux-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Ville Syrjälä 

I haven't seen the rest of this series, but this patch is OK by me,
and I assume you'll merge this along with the whole series.  Please
adjust the subject line to be:

  PCI: Decouple quirks.c from i915_reg.h

Acked-by: Bjorn Helgaas 

> ---
>  drivers/pci/quirks.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b03373f..78a70fb 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3404,7 +3404,9 @@ static int reset_intel_82599_sfp_virtfn(struct pci_dev 
> *dev, int probe)
>   return 0;
>  }
>  
> -#include "../gpu/drm/i915/i915_reg.h"
> +#define SOUTH_CHICKEN2   0xc2004
> +#define PCH_PP_STATUS0xc7200
> +#define PCH_PP_CONTROL   0xc7204
>  #define MSG_CTL  0x45010
>  #define NSDE_PWR_STATE   0xd0100
>  #define IGD_OPERATION_TIMEOUT1 /* set timeout 10 seconds */
> -- 
> 2.4.10
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [iGVT-g] XenGT for PV guest

[Oleksii Kurochko]

Hi all,

I am trying to enable XenGT for Android on board vtc1010 in PV mode.
Used:
- Intel® Atom™ processor E3827
- Xen 4.3.1 on branch "byt_experiment".
- dom0: ubuntu 14-04 with linux vgt 3.11.6-vgt+ kernel version
- domU: Android-IA 5.1 with 3.11.6-vgt+ (added Android configs)  kernel
version

vgt was successfully started in dom0.
vgt does not start in domU. After registration of pci dev in i915_init()
there is no call of i915_pci_driver.probe(). Inte HD Graphics is on pci
bus, but it is not passthrough to domU. When tried to passtrough it to domU
than dom0 crashes in drm_framebuffer_remove(). More than that it is not my
case because of intel hd graphics need to be working in dom0 and domU.

So could U give advice how to probe i915 driver in domU?

With best,
 Oleksii


-- 
Oleksii Kurochko | Embedded Dev
GlobalLogic
www.globallogic.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [i-g-t PATCH] tests: fix ddx_intel_after_fbdev to use intel_reg

[Jani Nikula]

intel_reg_dumper is gone, replaced by 'intel_reg dump'.

Signed-off-by: Jani Nikula 
---
 tests/ddx_intel_after_fbdev | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/ddx_intel_after_fbdev b/tests/ddx_intel_after_fbdev
index bcd2c29d8e9e..f068209d7a45 100755
--- a/tests/ddx_intel_after_fbdev
+++ b/tests/ddx_intel_after_fbdev
@@ -40,8 +40,8 @@ cp /var/log/Xorg.0.log $TMPDIR/Xorg.0.log.1.before.fbdev
 # run fbdev
 xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.fbdev & 
 sleep 5
-if [ -f `which intel_reg_dumper` ]; then
-`which intel_reg_dumper` > $TMPDIR/intel_reg_dumped.1.fbdev
+if [ -f `which intel_reg` ]; then
+`which intel_reg` dump > $TMPDIR/intel_reg_dump.1.fbdev
 fi
 killall X
 
@@ -54,8 +54,8 @@ sleep 5
 # run intel
 xinit -- /usr/bin/X -config $TMPDIR/xorg.conf.intel & 
 sleep 5 
-if [ -f `which intel_reg_dumper` ]; then
-`which intel_reg_dumper` > $TMPDIR/intel_reg_dumped.2.intel
+if [ -f `which intel_reg` ]; then
+`which intel_reg` dump > $TMPDIR/intel_reg_dump.2.intel
 fi
 killall X
 
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Zhang, Xiong Y]

> On Wed, 25 Nov 2015 10:56:51 +0100,
> Zhang, Xiong Y wrote:
> >
> > Recently I always see the following error message during S4 or S3 resume
> with drm-intel-nightly.
> > [   97.778063] PM: Syncing filesystems ... done.
> > [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
> done.
> > [   97.804297] PM: Marking nosave pages: [mem 0x-0x0fff]
> > [   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
> > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
> > [   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
> > [   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
> > [   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
> > [   97.804387] PM: Marking nosave pages: [mem 0x8800-0x]
> > [   97.806363] PM: Basic memory bitmaps created
> > [   97.806409] PM: Preallocating image memory... done (allocated 321557
> pages)
> > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> MB/s)
> > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 
> > seconds)
> done.
> > [   98.151998] Suspending console(s) (use no_console_suspend to debug)
> > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2:
> HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > [   99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> cmd=0x206f2e08
> > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0,
> force 128
> > [  101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout,
> switching to polling mode: last cmd=0x206f2f00
> > [  102.195492] snd_hda_intel :00:1f.3: No response from codec,
> disabling MSI: last cmd=0x206f2f00
> > [  103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout,
> switching to single_cmd mode: last cmd=0x206f2f00
> > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> >
> > The bisect result points to this commit.
> > I checked this patch and had one question: if i915 driver wake up ahead of
> snd_hda_intel driver during resume,  i915 driver will call audio driver's
> hdmi_present_sense() function through this patch, but the audio interrupt is
> disabled at this moment, how could hdmi_present_sense() get the response
> from codec ?
> 
> Yeah, a bad thing happens there.  The fix should be simple like below,
> though.  Basically the pins are checked in the resume callback in
> anyway, so there is no need to handle the notification during PM.
> 
> Could you check whether it works?
> 
> 
> thanks,
> 
> Takashi

Strange, your patch couldn't get away the error message.

thanks
> 
> ---
> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
> index bdb6f226d006..b468fe0e6195 100644
> --- a/sound/pci/hda/patch_hdmi.c
> +++ b/sound/pci/hda/patch_hdmi.c
> @@ -2352,7 +2352,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int
> port)
>   struct hda_codec *codec = audio_ptr;
>   int pin_nid = port + 0x04;
> 
> - check_presence_and_report(codec, pin_nid);
> + /* don't call notifier during PM; will be checked in resume callback */
> + if (!atomic_read(>core.in_pm))
> + check_presence_and_report(codec, pin_nid);
>  }
> 
>  static int patch_generic_hdmi(struct hda_codec *codec)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Disable FLT if DP config changes

[Mika Kahola]

Disable DP fast link training if DP link configuration
changes. If one of the DP link parameters i.e. link
bandwidth, lane count, rate selection, port clock or bpp
changes the link training does no longer apply the
previously computed voltage swing and pre-emphasis values.
Instead, the link training is started with zero values.

The patch is fix for reported screen flickering issue in

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

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dp.c   |  6 ++
 drivers/gpu/drm/i915/intel_dp_link_training.c | 27 +++
 drivers/gpu/drm/i915/intel_drv.h  |  6 +-
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2805f0d..3694e3f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1621,6 +1621,12 @@ found:
intel_dp_compute_rate(intel_dp, pipe_config->port_clock,
  _bw, _select);
 
+   intel_dp->link_bw = link_bw;
+   intel_dp->rate_select = rate_select;
+   intel_dp->lane_count = lane_count;
+   intel_dp->port_clock = pipe_config->port_clock;
+   intel_dp->bpp = bpp;
+
DRM_DEBUG_KMS("DP link bw %02x rate select %02x lane count %d clock %d 
bpp %d\n",
  link_bw, rate_select, pipe_config->lane_count,
  pipe_config->port_clock, bpp);
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 793..36a5294 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -82,9 +82,31 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
 }
 
 static bool
+intel_dp_check_conf(struct intel_dp *intel_dp)
+{
+   if (intel_dp->link_bw != intel_dp->old_link_bw)
+   return false;
+   else if (intel_dp->lane_count != intel_dp->old_lane_count)
+   return false;
+   else if (intel_dp->rate_select != intel_dp->old_rate_select)
+   return false;
+   else if (intel_dp->port_clock != intel_dp->old_port_clock)
+   return false;
+   else if (intel_dp->bpp != intel_dp->old_bpp)
+   return false;
+   else
+   return true;
+}
+
+static bool
 intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
 {
+   intel_dp->train_set_valid &= intel_dp_check_conf(intel_dp);
+
+   DRM_DEBUG_KMS("flt enabled: %s\n",
+ intel_dp->train_set_valid ? "true" : "false");
+
if (!intel_dp->train_set_valid)
memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
@@ -305,6 +327,11 @@ intel_dp_link_training_channel_equalization(struct 
intel_dp *intel_dp)
 
if (channel_eq) {
intel_dp->train_set_valid = true;
+   intel_dp->old_link_bw = intel_dp->link_bw;
+   intel_dp->old_rate_select = intel_dp->rate_select;
+   intel_dp->old_lane_count = intel_dp->lane_count;
+   intel_dp->old_port_clock = intel_dp->port_clock;
+   intel_dp->old_bpp = intel_dp->bpp;
DRM_DEBUG_KMS("Channel EQ done. DP Training successful\n");
}
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fae824..8db9288 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -742,7 +742,11 @@ struct intel_dp {
i915_reg_t aux_ch_data_reg[5];
uint32_t DP;
int link_rate;
-   uint8_t lane_count;
+   uint8_t lane_count, old_lane_count;
+   uint8_t link_bw, old_link_bw;
+   uint8_t rate_select, old_rate_select;
+   int port_clock, old_port_clock;
+   int bpp, old_bpp;
bool has_audio;
enum hdmi_force_audio force_audio;
bool limited_color_range;
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines

[Ville Syrjälä]

On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> > > > From: Akash Goel 
> > > > 
> > > > When the object is moved out of CPU read domain, the cachelines
> > > > are not invalidated immediately. The invalidation is deferred till
> > > > next time the object is brought back into CPU read domain.
> > > > But the invalidation is done unconditionally, i.e. even for the case
> > > > where the cachelines were flushed previously, when the object moved out
> > > > of CPU write domain. This is avoidable and would lead to some 
> > > > optimization.
> > > > Though this is not a hypothetical case, but is unlikely to occur often.
> > > > The aim is to detect changes to the backing storage whilst the
> > > > data is potentially in the CPU cache, and only clflush in those case.
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Signed-off-by: Akash Goel 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > >  drivers/gpu/drm/i915/i915_gem.c | 9 -
> > > >  2 files changed, 9 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index df9316f..fedb71d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> > > > unsigned long gt_ro:1;
> > > > unsigned int cache_level:3;
> > > > unsigned int cache_dirty:1;
> > > > +   unsigned int cache_clean:1;
> > > 
> > > So now we have cache_dirty and cache_clean which seems redundant,
> > > except somehow cache_dirty != !cache_clean?
> 
> Exactly, not entirely redundant. I did think something along MESI lines
> would be useful, but that didn't capture the different meanings we
> employ.
> 
> cache_dirty tracks whether we have been eliding the clflush.
> 
> cache_clean tracks whether we know the cache has been completely
> clflushed.

Can we know that with speculative prefetching and whatnot?

> 
> (cache_clean implies !cache_dirty, but
> !cache_clean does not imply cache_dirty)
> 
> > We also have read_domains & DOMAIN_CPU. Which is which?
> 
> DOMAIN_CPU implies that the object may be in the cpu cache (modulo the
> clflush elision above).
> 
> DOMAIN_CPU implies !cache_clean
> 
> and even
> 
> cache_clean implies !DOMAIN_CPU
> 
> but
> 
> !DOMAIN_CPU does not imply cache_clean
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
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 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Wed, 25 Nov 2015 11:57:13 +0100,
Zhang, Xiong Y wrote:
> 
> > On Wed, 25 Nov 2015 10:56:51 +0100,
> > Zhang, Xiong Y wrote:
> > >
> > > Recently I always see the following error message during S4 or S3 resume
> > with drm-intel-nightly.
> > > [   97.778063] PM: Syncing filesystems ... done.
> > > [   97.801550] Freezing user space processes ... (elapsed 0.002 seconds)
> > done.
> > > [   97.804297] PM: Marking nosave pages: [mem 0x-0x0fff]
> > > [   97.804302] PM: Marking nosave pages: [mem 0x00058000-0x00058fff]
> > > [   97.804305] PM: Marking nosave pages: [mem 0x0009e000-0x000f]
> > > [   97.804310] PM: Marking nosave pages: [mem 0x84c11000-0x84c12fff]
> > > [   97.804312] PM: Marking nosave pages: [mem 0x876fc000-0x87746fff]
> > > [   97.804317] PM: Marking nosave pages: [mem 0x8785e000-0x87fe9fff]
> > > [   97.804387] PM: Marking nosave pages: [mem 0x8800-0x]
> > > [   97.806363] PM: Basic memory bitmaps created
> > > [   97.806409] PM: Preallocating image memory... done (allocated 321557
> > pages)
> > > [   98.150475] PM: Allocated 1286228 kbytes in 0.34 seconds (3783.02
> > MB/s)
> > > [   98.150476] Freezing remaining freezable tasks ... (elapsed 0.001 
> > > seconds)
> > done.
> > > [   98.151998] Suspending console(s) (use no_console_suspend to debug)
> > > [   98.173485] hdmi_present_sense: snd_hda_codec_hdmi hdaudioC0D2:
> > HDMI status: Codec=2 Pin=6 Presence_Detect=1 ELD_Valid=1
> > > [   99.178150] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178151] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178152] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178153] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178154] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178155] snd_hda_intel :00:1f.3: spurious response 0x0:0x2, last
> > cmd=0x206f2e08
> > > [   99.178162] snd_hda_codec_hdmi hdaudioC0D2: HDMI: ELD buf size is 0,
> > force 128
> > > [  101.189709] snd_hda_intel :00:1f.3: azx_get_response timeout,
> > switching to polling mode: last cmd=0x206f2f00
> > > [  102.195492] snd_hda_intel :00:1f.3: No response from codec,
> > disabling MSI: last cmd=0x206f2f00
> > > [  103.201275] snd_hda_intel :00:1f.3: azx_get_response timeout,
> > switching to single_cmd mode: last cmd=0x206f2f00
> > > [  103.201396] azx_single_wait_for_response: 42 callbacks suppressed
> > >
> > > The bisect result points to this commit.
> > > I checked this patch and had one question: if i915 driver wake up ahead of
> > snd_hda_intel driver during resume,  i915 driver will call audio driver's
> > hdmi_present_sense() function through this patch, but the audio interrupt is
> > disabled at this moment, how could hdmi_present_sense() get the response
> > from codec ?
> > 
> > Yeah, a bad thing happens there.  The fix should be simple like below,
> > though.  Basically the pins are checked in the resume callback in
> > anyway, so there is no need to handle the notification during PM.
> > 
> > Could you check whether it works?
> > 
> > 
> > thanks,
> > 
> > Takashi
> 
> Strange, your patch couldn't get away the error message.

OK, then it's not about the race *during* the hd-audio driver
resuming or such.  I guess it's the other way round: the i915 driver
notifies it unnecessarily while it's getting off.  The audio part of
HDMI controller relies on the i915 power state, so it's screwed up.

Check with drm.debug option to see in which code path it's triggered.
If it's a call in i915 suspend, the call should be removed not to wake
up the audio part unnecessarily.

BTW, I have a patchset to avoid the audio h/w wakeup by a new
component ops to get ELD and connection states.  It was posted to
alsa-devel shortly ago just as a reference, but this should work well
in such a case, too.  The test patches are found in test/hdmi-jack
branch of my sound git tree.


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

[Intel-gfx] [PATCH i-g-t] scripts: Add feature list file for piglit 'summary feature'

[Gabriel Feceoru]

This is a placeholder for the feature list file. Its content is just
an example.
This needs to be filled in by feature owners with the feature name
and the corresponding tests regex.

Please refer to this piglit commit for more info on this feature.

commit f16d011db75b08ceae241e7370599146691340ab
Author: Feceoru, Gabriel 
Date:   Tue Nov 3 17:50:41 2015 +0200

framework: Add support for feature readiness.

Signed-off-by: Gabriel Feceoru 
---
 scripts/feat_profile.json | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 scripts/feat_profile.json

diff --git a/scripts/feat_profile.json b/scripts/feat_profile.json
new file mode 100644
index 000..f3a21a3
--- /dev/null
+++ b/scripts/feat_profile.json
@@ -0,0 +1,12 @@
+{
+"glsl" : {
+"include_tests" : "glsl",
+"exclude_tests" : "",
+"target_rate" : 90
+},
+"arb" : {
+"include_tests" : "ARB_shader|deqp.arb shader",
+"exclude_tests" : "",
+"target_rate" : 10
+}
+}
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request

[Chris Wilson]

On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote:
> > On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote:
> > > > Instead of querying the reset counter before every access to the ring,
> > > > query it the first time we touch the ring, and do a final compare when
> > > > submitting the request. For correctness, we need to then sanitize how
> > > > the reset_counter is incremented to prevent broken submission and
> > > > waiting across resets, in the process fixing the persistent -EIO we
> > > > still see today on failed waits.
> > > 
> > > tbh that explanation went straight over my head. Questions:
> > > - Where do we wait again over a reset? With all the wakeups we should
> > >   catch them properly. I guess this needs the detailed scenario to help me
> > >   out, since I have dim memories that there is something wrong ;-)
> > 
> > TDR. In the future (and in past speculative patches) we have proposed
> > keeping requests over a reset and requeuing them. That is a complication
> > to the simplification of bailing out from the wait. What I have in mind,
> > is the recovery code has to fix up the request list somehow, though that
> > will be fun.
> 
> But even with requeueing the waiters need to bail out and restart the
> ioctl. So I don't see why requeueing of requests matter.

But why should the waiter even wake up? It is not holding any locks, all
it is just waiting for the request to complete. It is only those holding
a lock required to reset that we need to kick.
 
> And my question was about what exactly is broken when waiting over a
> reset? As long as we detect the reset and restart the ioctl we should pick
> up any kinds of state fixups the reset work has done and recover
> perfectly. Irrespective of whether the reset work has requeued some of the
> requests or not.

But... The reset handler clears the requests, we cannot wait over a
reset. So waiting over a reset today is clearly a bug in the kernel.

Only in the future do we contemplate situations where a request may
survive a reset.
 
> > > - What precisely is the effect for waiters? I only see moving the
> > >   atomic_inc under the dev->struct_mutex, which shouldn't do a hole lot
> > >   for anyone. Plus not returning -EAGAIN when reset_in_progress, which
> > >   looks like it might result in missed wakeups and deadlocks with the
> > >   reset work.
> > 
> > At the moment, I can trivially wedge the machine. This patch fixes that.
> > The patch also ensures that we cannot raise unhandled errors from
> > wait-request (EIO/EAGAIN handling has to be explicitly added to the
> > caller).
> 
> Hm, how/where do we wedge the machine, and how does the fix work?

Being able to reset a previously wedged machine.

> > The wait-request interface still has the wait-seqno legacy of having to
> > acquire the reset_counter under the mutex before calling. That is quite
> > hairy and causes a major complication later where we want to amalgamate
> > waiters.
> 
> Yeah, that's a sensible change. But since I don't yet understand where
> exactly the current logic results in a wedge gpu I can't convince myself
> that the new one is ok.
> 
> > Re EAGAIN. No, it cannot result in missed wakeups since that is internal
> > to the wait_request function, nor can it result in new deadlocks with the
> > reset worker.
> 
> Yeah I think today with just struct_mutex it's impossible. But if we have
> more locks the waiting thread could continue to grab more locks instead of
> bailing out straight. And then the reset handler would be somewhat screwed
> since it isn't guaranteed to make forward progress.

So basically if you add a deadlock/livelock, it may deadlock/livelock.
 
> > > I /thought/ that the -EIO is from check_wedge in intel_ring_begin, but
> > > that part seems essentially unchanged.
> > 
> > For two reasons, we need to to protect the access to the ring, and you
> > argued that (reporting of EIO from previous wedged GPUs) it was part of
> > the ABI. The other ABI that I think is important, is the reporting of
> > EIO if the user explicits waits on a request and it is incomplete (i.e.
> > wait_ioctl).
> 
> Well then I don't get where the -EIO is from. That leaves a truly wedge
> gpu as the cause, and for that case I don't get how it can happen by
> accident with the current code.

We fail a reset, or to recover. Happens often enough.

> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index ffd99d27fac7..5838882e10a1 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -841,23 +841,31 @@ int i915_resume_legacy(struct drm_device *dev)
> > > >  int i915_reset(struct drm_device *dev)
> > > >  {
> > > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > > +   struct i915_gpu_error *error = 

Re: [Intel-gfx] [MIPI CABC 1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT

[Jani Nikula]

On Mon, 16 Nov 2015, Deepak M  wrote:
> For dual link panel scenarios there are new fileds added in the
> VBT which indicate on which port the PWM cntrl and CABC ON/OFF
> commands needs to be sent.
>
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Yetunde Adebisi 
> Signed-off-by: Deepak M 
> ---
>  drivers/gpu/drm/i915/intel_bios.c | 13 +
>  drivers/gpu/drm/i915/intel_bios.h |  5 -
>  drivers/gpu/drm/i915/intel_dsi.h  |  2 ++
>  3 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index ce82f9c..2ef8721 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -793,6 +793,19 @@ parse_mipi(struct drm_i915_private *dev_priv, const 
> struct bdb_header *bdb)
>   return;
>   }
>  
> + /*
> +  * These below bits will inform us on which port the panel blk_cntrl and
> +  * CABC ON/OFF commands needs to be sent in case of dual link panels
> +  *  u16 dl_cabc_port:2;
> +  *  u16 pwm_bkl_ctrl:2;
> +  * But these are introduced from the VBT version 197 onwards, so making
> +  * sure that these bits are zero in the pervious versions.
> +  */
> + if (dev_priv->vbt.dsi.config->dual_link && bdb->version < 197) {
> + dev_priv->vbt.dsi.config->dl_cabc_port = 0;
> + dev_priv->vbt.dsi.config->pwm_bkl_ctrl = 0;
> + }
> +

dev_priv->vbt is zero by default, so none of the above is needed.

>   /* We have mandatory mipi config blocks. Initialize as generic panel */
>   dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
>  
> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
> b/drivers/gpu/drm/i915/intel_bios.h
> index 7ec8c9a..9283969 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -832,7 +832,10 @@ struct mipi_config {
>   u16 dual_link:2;
>   u16 lane_cnt:2;
>   u16 pixel_overlap:3;
> - u16 rsvd3:9;
> + u16 rgb_flip:1;
> + u16 dl_cabc_port:2;
> + u16 pwm_bkl_ctrl:2;
> + u16 rsvd3:4;
>  
>   u16 rsvd4;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h 
> b/drivers/gpu/drm/i915/intel_dsi.h
> index e6cb252..4fde83b 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -74,6 +74,8 @@ struct intel_dsi {
>  
>   u8 escape_clk_div;
>   u8 dual_link;
> + u8 bkl_dcs_ports;
> + u8 pwm_blk_ctrl;

This is a much more natural place to explain what these things do.

>   u8 pixel_overlap;
>   u32 port_bits;
>   u32 bw_timer;

-- 
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] [MIPI CABC 1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT

[Jani Nikula]

On Wed, 25 Nov 2015, Jani Nikula  wrote:
> On Mon, 16 Nov 2015, Deepak M  wrote:
>> For dual link panel scenarios there are new fileds added in the
>> VBT which indicate on which port the PWM cntrl and CABC ON/OFF
>> commands needs to be sent.
>>
>> Cc: Jani Nikula 
>> Cc: Daniel Vetter 
>> Cc: Yetunde Adebisi 
>> Signed-off-by: Deepak M 
>> ---
>>  drivers/gpu/drm/i915/intel_bios.c | 13 +
>>  drivers/gpu/drm/i915/intel_bios.h |  5 -
>>  drivers/gpu/drm/i915/intel_dsi.h  |  2 ++
>>  3 files changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index ce82f9c..2ef8721 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -793,6 +793,19 @@ parse_mipi(struct drm_i915_private *dev_priv, const 
>> struct bdb_header *bdb)
>>  return;
>>  }
>>  
>> +/*
>> + * These below bits will inform us on which port the panel blk_cntrl and
>> + * CABC ON/OFF commands needs to be sent in case of dual link panels
>> + *  u16 dl_cabc_port:2;
>> + *  u16 pwm_bkl_ctrl:2;
>> + * But these are introduced from the VBT version 197 onwards, so making
>> + * sure that these bits are zero in the pervious versions.
>> + */
>> +if (dev_priv->vbt.dsi.config->dual_link && bdb->version < 197) {
>> +dev_priv->vbt.dsi.config->dl_cabc_port = 0;
>> +dev_priv->vbt.dsi.config->pwm_bkl_ctrl = 0;
>> +}
>> +
>
> dev_priv->vbt is zero by default, so none of the above is needed.

Ugh, I didn't realize we just copy the dsi.config verbatim from
VBT. Maybe we do want this after all.


>
>>  /* We have mandatory mipi config blocks. Initialize as generic panel */
>>  dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
>>  
>> diff --git a/drivers/gpu/drm/i915/intel_bios.h 
>> b/drivers/gpu/drm/i915/intel_bios.h
>> index 7ec8c9a..9283969 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.h
>> +++ b/drivers/gpu/drm/i915/intel_bios.h
>> @@ -832,7 +832,10 @@ struct mipi_config {
>>  u16 dual_link:2;
>>  u16 lane_cnt:2;
>>  u16 pixel_overlap:3;
>> -u16 rsvd3:9;
>> +u16 rgb_flip:1;
>> +u16 dl_cabc_port:2;
>> +u16 pwm_bkl_ctrl:2;
>> +u16 rsvd3:4;
>>  
>>  u16 rsvd4;
>>  
>> diff --git a/drivers/gpu/drm/i915/intel_dsi.h 
>> b/drivers/gpu/drm/i915/intel_dsi.h
>> index e6cb252..4fde83b 100644
>> --- a/drivers/gpu/drm/i915/intel_dsi.h
>> +++ b/drivers/gpu/drm/i915/intel_dsi.h
>> @@ -74,6 +74,8 @@ struct intel_dsi {
>>  
>>  u8 escape_clk_div;
>>  u8 dual_link;
>> +u8 bkl_dcs_ports;
>> +u8 pwm_blk_ctrl;
>
> This is a much more natural place to explain what these things do.
>
>>  u8 pixel_overlap;
>>  u32 port_bits;
>>  u32 bw_timer;

-- 
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 05/12] drm/i915: Kill off intel_crtc->atomic.wait_vblank, v2.

[Ander Conselvan De Oliveira]

On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
> 
> Merge them by creating a helper function that takes a crtc mask
> for the planes to wait on.
> 
> The broadwell vblank workaround may look gone entirely but this is
> not the case. pipe_config->wm_changed is set to true
> when any plane is turned on, which forces a vblank wait.
> 
> Changes since v1:
> - Removing the double vblank wait on broadwell moved to its own commit.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_atomic.c  |  1 +
>  drivers/gpu/drm/i915/intel_display.c | 88 ++-
> -
>  drivers/gpu/drm/i915/intel_drv.h |  2 +-
>  3 files changed, 65 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 4625f8a9ba12..8e579a8505ac 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -97,6 +97,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
>   crtc_state->disable_lp_wm = false;
>   crtc_state->disable_cxsr = false;
>   crtc_state->wm_changed = false;
> + crtc_state->fb_changed = false;
>  
>   return _state->base;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 60f17bc5f0ce..299edbf6f99e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4738,9 +4738,6 @@ static void intel_post_plane_update(struct intel_crtc
> *crtc)
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> - if (atomic->wait_vblank)
> - intel_wait_for_vblank(dev, crtc->pipe);
> -
>   intel_frontbuffer_flip(dev, atomic->fb_bits);
>  
>   crtc->wm.cxsr_allowed = true;
> @@ -4754,6 +4751,9 @@ static void intel_post_plane_update(struct intel_crtc
> *crtc)
>   if (atomic->post_enable_primary)
>   intel_post_enable_primary(>base);
>  
> + if (needs_modeset(_config->base))
> + intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
> +
>   memset(atomic, 0, sizeof(*atomic));
>  }
>  
> @@ -11693,6 +11693,9 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (!was_visible && !visible)
>   return 0;
>  
> + if (fb != old_plane_state->base.fb)
> + pipe_config->fb_changed = true;
> +
>   turn_off = was_visible && (!visible || mode_changed);
>   turn_on = visible && (!was_visible || mode_changed);
>  
> @@ -11708,8 +11711,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>  
>   /* must disable cxsr around plane enable/disable */
>   if (plane->type != DRM_PLANE_TYPE_CURSOR) {
> - if (is_crtc_enabled)
> - intel_crtc->atomic.wait_vblank = true;
>   pipe_config->disable_cxsr = true;
>   }
>   } else if ((was_visible || visible) &&
> @@ -11757,14 +11758,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   plane_state->rotation != BIT(DRM_ROTATE_0))
>   intel_crtc->atomic.disable_fbc = true;
>  
> - /*
> -  * BDW signals flip done immediately if the plane
> -  * is disabled, even if the plane enable is already
> -  * armed to occur at the next vblank :(
> -  */
> - if (turn_on && IS_BROADWELL(dev))
> - intel_crtc->atomic.wait_vblank = true;
> -
>   intel_crtc->atomic.update_fbc |= visible || mode_changed;
>   break;
>   case DRM_PLANE_TYPE_CURSOR:
> @@ -11779,12 +11772,10 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
>   if (IS_IVYBRIDGE(dev) &&
>   needs_scaling(to_intel_plane_state(plane_state)) &&
>   !needs_scaling(old_plane_state)) {
> - to_intel_crtc_state(crtc_state)->disable_lp_wm =
> true;
> - } else if (turn_off && !mode_changed) {
> - intel_crtc->atomic.wait_vblank = true;
> + pipe_config->disable_lp_wm = true;
> + } else if (turn_off && !mode_changed)
>   intel_crtc->atomic.update_sprite_watermarks |=
>   1 << i;
> - }

Did you intend to delete the braces on both sides of the if? Sorry, OCD. :)

Other than this and the comment on the other thread were I added Patrik and
Imre, this looks good.

Ander


>  
>   break;
>   }
> @@ -13299,6 +13290,48 @@ static int