Re: [Intel-gfx] panning crash

2015-06-13 Thread Felix Miata
Chris Wilson composed on 2015-06-13 09:19 (UTC+0100):

Thank you for responding!

 On Sat, Jun 13, 2015 at 02:17:34AM -0400, Felix Miata wrote:

 Dell Optiplex GX280
 P4 32 bit Hyperthreading enabled 0F34 2.8GHz CPU
 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL 
 Integrated Graphics Controller (rev 04)
 
 /etc/X11/xinit/xinitrc.d/setup contains:
 xrandr --fbmm 387x218 --fb 2560x1440 --output VGA1 --mode 1920x1440 
 --panning 2560x1440
 
 Panning mouse out of initial CRTC desktop space into virtual desktop space 
 and back in
 some installations causes crash, in others not. Can someone here tell if 
 this is a kernel,
 server or other issue and not a driver issue from a look at Xorg.0.log? My 
 suspicion is
 kernel as primary if not sole.

 I think the crash is in the rejection handling code. If the kernel
 rejects the modeset, we try again with via a shadow. The crash is very
 unexpected. You can run the stacktraces though addr2line (e.g.
 addr2line -i -e /usr/lib/xorg/modules/drivers/intel_drv.so 0x638f7
 0x68fbc 0x6a02b)

Brief googling this didn't find anything I can grok. It's probably doable with
minimal hand-holding, e.g. a URL explaining what tools need to be installed
(gdb + ???) and how to use them. Debugging is something I do so infrequently I
forget everything I managed to slog through from one session to the next.

 but also compiling your own ddx with
 --enable-debug=full would be very useful.

Not doable. I tried programming in college over 4 decades ago. English remains
as much language as I can cope with, and not even that much WRT OBS. OTOH, RPMs
I can deal with.

 A drm.debug=6 dmesg would tell you what is going on kernel side.

Tell you maybe. :-)

http://fm.no-ip.com/Tmp/Linux/Xorg/Igfx/panfault/

Fedora 21, kernel 4.0.4:
dmsg-i915G-f21-k404crash.txt

Tumbleweed, kernel 4.0.4:
dmsg-i915G-os133-k404crash.txt

Looks like maybe the crash occurred in the vicinity of [433.26] in F21,
[111.57] in TW, but there's minimal sense I can make of dmesg generally.

All this said, crash didn't happen in Rawhide, so maybe it's a kernel
problem that has resolved itself post-4.0.4?

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

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

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


Re: [Intel-gfx] [PATCH v3] drm/i915 : Added Programming of the MOCS

2015-06-13 Thread shuang . he
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6561
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  303/303  303/303
SNB  312/312  312/312
IVB  343/343  343/343
BYT  287/287  287/287
BDW  321/321  321/321
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm: Turn off Legacy Context Functions

2015-06-13 Thread shuang . he
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6560
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  303/303  303/303
SNB  312/312  312/312
IVB  343/343  343/343
BYT  287/287  287/287
BDW  321/321  321/321
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] panning crash

2015-06-13 Thread Felix Miata
Dell Optiplex GX280
P4 32 bit Hyperthreading enabled 0F34 2.8GHz CPU
00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated 
Graphics Controller (rev 04)

/etc/X11/xinit/xinitrc.d/setup contains:
xrandr --fbmm 387x218 --fb 2560x1440 --output VGA1 --mode 1920x1440 --panning 
2560x1440

Panning mouse out of initial CRTC desktop space into virtual desktop space and 
back in
some installations causes crash, in others not. Can someone here tell if this 
is a kernel,
server or other issue and not a driver issue from a look at Xorg.0.log? My 
suspicion is
kernel as primary if not sole.

Successes:
Rawhide, kernel 4.1.0-0.rc7, driver 2.99.917, server 1.17.1, KDE5
Mageia 5, kernel 3.19.8, driver 2.99.917, server 1.16.4, KDE4
openSUSE 13.1, kernel 3.12.39, driver 2.99.917, server 1.15.99.903, KDE3
openSUSE 13.2, kernel 3.16.7, driver 2.99.917, server 1.17.1, KDE3

Failures:
Fedora 21, kernel 4.0.4, driver 2.99.916, server 1.16.3, KDE4
Tumbleweed, kernel 4.0.4, driver 2.99.917, server 1.17.1, KDE3

Skipped testing due to unrelated issue (refuses mode 1920x1440 that xrandr 
claims
available, uses 1600x1200 instead, and no crashing):
Fedora 22, kernel 4.0.5, driver 2.99.917, server 1.17.1, KDE5

Logs:
http://fm.no-ip.com/Tmp/Linux/Xorg/Igfx/panfault/
-- 
The wise are known for their understanding, and pleasant
words are persuasive. Proverbs 16:21 (New Living Translation)

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

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


Re: [Intel-gfx] [RFC 11/14] drm/i915: Enable MIPI display self refresh mode

2015-06-13 Thread Mohan Marimuthu, Yogesh



On 5/29/2015 10:51 PM, Daniel Vetter wrote:

On Fri, May 29, 2015 at 04:07:03PM +0530, Gaurav K Singh wrote:

During enable sequence for MIPI encoder in command mode, enable
MIPI display self-refresh mode bit in Pipe Ctrl reg.

Signed-off-by: Gaurav K Singh gaurav.k.si...@intel.com
Signed-off-by: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
  drivers/gpu/drm/i915/intel_display.c |   15 +++
  1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index cab2ac8..fc84313 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -44,6 +44,7 @@
  #include drm/drm_plane_helper.h
  #include drm/drm_rect.h
  #include linux/dma_remapping.h
+#include intel_dsi.h
  
  /* Primary plane formats supported by all gen */

  #define COMMON_PRIMARY_FORMATS \
@@ -2110,6 +2111,8 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
  {
struct drm_device *dev = crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+   struct intel_encoder *encoder;
+   struct intel_dsi *intel_dsi;
enum pipe pipe = crtc-pipe;
enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
  pipe);
@@ -2154,6 +2157,18 @@ static void intel_enable_pipe(struct intel_crtc *crtc)
return;
}
  
+	for_each_encoder_on_crtc(dev, crtc-base, encoder) {

+   if (encoder-type == INTEL_OUTPUT_DSI) {
+   intel_dsi = enc_to_intel_dsi(encoder-base);
+   if (intel_dsi  (intel_dsi-operation_mode ==
+   INTEL_DSI_COMMAND_MODE)) {
+   val = val | PIPECONF_MIPI_DSR_ENABLE;
+   I915_WRITE(reg, val);
+   }
+   break;
+   }
+   }

When we have these kind of encoder/crtc state depencies we resolve them by
adding a bit of state to intel_crtc_state which is set as needed in the
encoder's compute_config callback. Then all you need here is

if (intel_state-dsi_self_refresh)
val |= PIPECONF_MIPI_DSR_ENABLE;

Also is that additional write really required?
-Daniel
Yes additional write is required. MIPI_DSR_ENABLE has to be written 
first then followed
by pipe enable. if MIPI_DSR_ENABLE and pipe enable is done in same 
write, observed

that the image from pipe is not sent to panel when issued mem write command.

Having a state variable instead of looping through the encoders 
definitely looks good.

Need to find a place to update the state variable. I will get back on this.

+
I915_WRITE(reg, val | PIPECONF_ENABLE);
POSTING_READ(reg);
  }
--
1.7.9.5

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


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


Re: [Intel-gfx] panning crash

2015-06-13 Thread Chris Wilson
On Sat, Jun 13, 2015 at 02:17:34AM -0400, Felix Miata wrote:
 Dell Optiplex GX280
 P4 32 bit Hyperthreading enabled 0F34 2.8GHz CPU
 00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL 
 Integrated Graphics Controller (rev 04)
 
 /etc/X11/xinit/xinitrc.d/setup contains:
 xrandr --fbmm 387x218 --fb 2560x1440 --output VGA1 --mode 1920x1440 --panning 
 2560x1440
 
 Panning mouse out of initial CRTC desktop space into virtual desktop space 
 and back in
 some installations causes crash, in others not. Can someone here tell if this 
 is a kernel,
 server or other issue and not a driver issue from a look at Xorg.0.log? My 
 suspicion is
 kernel as primary if not sole.

I think the crash is in the rejection handling code. If the kernel
rejects the modeset, we try again with via a shadow. The crash is very
unexpected. You can run the stacktraces though addr2line (e.g.
addr2line -i -e /usr/lib/xorg/modules/drivers/intel_drv.so 0x638f7
0x68fbc 0x6a02b) but also compiling your own ddx with
--enable-debug=full would be very useful. A drm.debug=6 dmesg would tell
you what is going on kernel side.
-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] drm/i915: prevent out of range pt in the PDE macros (take 2)

2015-06-13 Thread Chris Wilson
On Fri, Jun 12, 2015 at 06:30:56PM -0300, Paulo Zanoni wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com
 
 We tried to fix this in the following commit:
 
 commit fdc454c1484a20e1345cf4e4d7a9feaee814147f
 Author: Michel Thierry michel.thie...@intel.com
 Date:   Tue Mar 24 15:46:19 2015 +
 drm/i915: Prevent out of range pt in gen6_for_each_pde
 
 but the static analyzer still complains that, just before we break due
 to iter  I915_PDES, we do pt = (pd)-page_table[iter] with an
 iter value that is bigger than I915_PDES. Of course, this isn't really
 a problem since no one uses pt outside the macro. Still, every single
 new usage of the macro will create a new issue for us to mark as a
 false possitive.
 
 After the commit mentioned above we also created some new versions of
 the macros, so they carry the same problem.
 
 In order to solve this problem, let's leave the macro with a NULL
 value for pt. So if somebody uses it, we're more likely to get a big
 error message instead of some silent failure. I hope the static
 analyzer won't complain about the new solution (I don't have a way to
 check this!).
 
 I know, the solution looks really ugly. I am hoping the reviewers will
 help us decide if we prefer this patch or if we prefer to keep marking
 things as false positives.
 
 Cc: Michel Thierry michel.thie...@intel.com
 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
  drivers/gpu/drm/i915/i915_gem_gtt.h | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)
 
 I sent this as an RFC because I really don't know if complicating the
 macro even more will help us in any way. I won't really be surprised
 if I see NACKs on this patch, so don't hesitate if you want to.
 
 Also, all I did was boot a Kernel with this patch and make sure it
 shows the desktop. So consider this as untested, possibly broken.
 
 diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
 b/drivers/gpu/drm/i915/i915_gem_gtt.h
 index 0d46dd2..b202ca0 100644
 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
 +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
 @@ -352,7 +352,8 @@ struct i915_hw_ppgtt {
   */

Overallocate page_table etc by one and put a NULL sentinel in it.

for ((iter) = gen6_pde_index(start); \
 (length)  0  (pt = (pd)-page_table[iter]); \
 (iter)++, \
 temp = ALIGN(start+1, 1  GEN6_PDE_SHIFT) - start, \
 temp = min_t(unsigned, temp, length), \

-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 5/5] drm/i915: Enable PSR by default.

2015-06-13 Thread Rodrigo Vivi
Hi Matthew,

here is the patch I've mentioned on irc today:
http://cgit.freedesktop.org/~vivijim/drm-intel/commit/?h=psr_for_mjg59id=83809492138f2395bfb12c19e6de916de64b9246

And I prepared this branch for now:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=psr_for_mjg59

I'm not sending yet the patches because I still face the missed screen
during boot that you had mentioned. As soon as I fixed it I'll submit
everything.

Thanks,
Rodrigo.


On Mon, Apr 20, 2015 at 7:43 AM, Vivi, Rodrigo rodrigo.v...@intel.com wrote:
 On Sat, 2015-04-18 at 08:27 +0100, Matthew Garrett wrote:
 On Mon, Apr 13, 2015 at 04:46:29PM -0700, Rodrigo Vivi wrote:
  Another questions,
 
  Are you using powertop --auto-tune?
 
  If so, can you please try to repdoruce X slowness issue on these 2 
  scenarios:
  1. without doing the powertop auto-tune and psr enabled.

 Ah! Yes, this is the problem. If runtime PM is enabled on the i915 PCI
 device (and the HDMI HDA device), things break. If it's disabled,
 everything works fine. I hope that helps narrow it down!


 Are you using external USB keyboard and mouse? I can just face this
 slowness when using USB, if I don't use any USB everything is fine. If
 switch all USB powertop scripts to Bad I also can use my system
 reliably. This seems a bug in usb power management. Could you please
 verify if this is the same that I'm facing here?

 One extra thing, could you confirm that you face this behaviour even
 with i915.enable_psr=0 so Daniel can accept this last patch?

 Thank you very much,
 Rodrigo.



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 3/3] drm/i915: Expose I915_EXEC_RESOURCE_STREAMER flag

2015-06-13 Thread shuang . he
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6555
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  303/303  303/303
SNB  312/312  312/312
IVB  343/343  343/343
BYT  287/287  287/287
BDW  321/321  321/321
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Reinstate order of operations in {intel, logical}_ring_begin()

2015-06-13 Thread shuang . he
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6557
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  303/303  303/303
SNB  312/312  312/312
IVB  343/343  343/343
BYT  287/287  287/287
BDW  321/321  321/321
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: work around HW coherency issue for cached GEM mappings

2015-06-13 Thread shuang . he
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 6556
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
PNV  276/276  276/276
ILK  303/303  303/303
SNB  312/312  312/312
IVB  343/343  343/343
BYT  287/287  287/287
BDW  321/321  321/321
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx