date:20140609

On Mon, Jun 09, 2014 at 07:47:10AM +0100, Chris Wilson wrote:
 Thomas found that his machine would deadlock reloading the i915.ko
 module after resume. He identified that this was caused by the
 reacquisition of the connection mutex inside intel_enable_pipe_a()
 during the CRTC sanitization routine. This will only affect machines
 that quirk PIPE A, i.e. the original 830m chipsets.
 
 This patch move the locking into a wrapper function so that
 intel_enable_pipe_a() can bypass the locking knowing that it already
 holds the correct locks.

It can still try to grab crtc-mutex twice. Looks like Danial undid my
fix to not take all the modeset locks around
intel_modeset_setup_hw_state().

 
 Reported-by: Thomas Richter rich...@rus.uni-stuttgart.de
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Thomas Richter rich...@rus.uni-stuttgart.de
 Cc: Daniel Vetter dan...@ffwll.ch
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  drivers/gpu/drm/i915/intel_display.c |   54 
 ++
  1 file changed, 35 insertions(+), 19 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index c1f79a1..26d3424 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -8387,9 +8387,10 @@ mode_fits_in_fbdev(struct drm_device *dev,
  #endif
  }
  
 -bool intel_get_load_detect_pipe(struct drm_connector *connector,
 - struct drm_display_mode *mode,
 - struct intel_load_detect_pipe *old)
 +static bool
 +__intel_get_load_detect_pipe(struct drm_connector *connector,
 +  struct drm_display_mode *mode,
 +  struct intel_load_detect_pipe *old)
  {
   struct intel_crtc *intel_crtc;
   struct intel_encoder *intel_encoder =
 @@ -8405,7 +8406,7 @@ bool intel_get_load_detect_pipe(struct drm_connector 
 *connector,
 connector-base.id, connector-name,
 encoder-base.id, encoder-name);
  
 - mutex_lock(dev-mode_config.connection_mutex);
 + lockdep_assert_held(dev-mode_config.connection_mutex);
  
   /*
* Algorithm gets a little messy:
 @@ -8449,7 +8450,7 @@ bool intel_get_load_detect_pipe(struct drm_connector 
 *connector,
*/
   if (!crtc) {
   DRM_DEBUG_KMS(no pipe available for load-detect\n);
 - goto fail_unlock_connector;
 + return false;
   }
  
   mutex_lock(crtc-mutex);
 @@ -8503,14 +8504,13 @@ bool intel_get_load_detect_pipe(struct drm_connector 
 *connector,
   else
   intel_crtc-new_config = NULL;
   mutex_unlock(crtc-mutex);
 -fail_unlock_connector:
 - mutex_unlock(dev-mode_config.connection_mutex);
  
   return false;
  }
  
 -void intel_release_load_detect_pipe(struct drm_connector *connector,
 - struct intel_load_detect_pipe *old)
 +static void
 +__intel_release_load_detect_pipe(struct drm_connector *connector,
 +  struct intel_load_detect_pipe *old)
  {
   struct intel_encoder *intel_encoder =
   intel_attached_encoder(connector);
 @@ -8518,6 +8518,8 @@ void intel_release_load_detect_pipe(struct 
 drm_connector *connector,
   struct drm_crtc *crtc = encoder-crtc;
   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
  
 + lockdep_assert_held(connector-dev-mode_config.connection_mutex);
 +
   DRM_DEBUG_KMS([CONNECTOR:%d:%s], [ENCODER:%d:%s]\n,
 connector-base.id, connector-name,
 encoder-base.id, encoder-name);
 @@ -8533,17 +8535,32 @@ void intel_release_load_detect_pipe(struct 
 drm_connector *connector,
   drm_framebuffer_unregister_private(old-release_fb);
   drm_framebuffer_unreference(old-release_fb);
   }
 + } else {
 + /* Switch crtc and encoder back off if necessary */
 + if (old-dpms_mode != DRM_MODE_DPMS_ON)
 + connector-funcs-dpms(connector, old-dpms_mode);
 + }
 + mutex_unlock(crtc-mutex);
 +}
  
 - mutex_unlock(crtc-mutex);
 +bool intel_get_load_detect_pipe(struct drm_connector *connector,
 + struct drm_display_mode *mode,
 + struct intel_load_detect_pipe *old)
 +{
 + mutex_lock(connector-dev-mode_config.connection_mutex);
 + if (!__intel_get_load_detect_pipe(connector, mode, old)) {
   mutex_unlock(connector-dev-mode_config.connection_mutex);
 - return;
 + return false;
   }
  
 - /* Switch crtc and encoder back off if necessary */
 - if (old-dpms_mode != DRM_MODE_DPMS_ON)
 - connector-funcs-dpms(connector, old-dpms_mode);
 + /* lock will be released by intel_release_load_detect_pipe() */
 + return true;
 +}
  
 - mutex_unlock(crtc-mutex);
 +void

[Intel-gfx] [PATCH] Fixed the review issues for pm_rc6_residency IGT case

2014-06-09 Thread Wendy Wang

Why need add rc6_residency_counter subtest case:
RC6 feature support residency counter,from power consumption aspect,
the counter closer to 1,the better.If the counter is  0.9, the residency
is not good and will impact power consumption value, if the counter is   1,
sysfs file is inaccurate.

Attach the test result message:
root@x-bdw05:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# ./pm_rc6_residency
IGT-Version: 1.6-g9a70e29 (x86_64) (Linux: 
3.15.0-rc7_drm-intel-nightly_0a37b5_20140604+ x86_64)
Subtest rc6-residency-check: SUCCESS
This machine doesn't support rc6pp
This machine doesn't support rc6p
The residency counter : 0.987000
This machine entry rc6 state.
Subtest rc6-residency-counter: SUCCESS

root@x-bdw05:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# 
./pm_rc6_residency --run-subtest rc6-residency-counter
IGT-Version: 1.6-g9a70e29 (x86_64) (Linux: 
3.15.0-rc7_drm-intel-nightly_0a37b5_20140604+ x86_64)
This machine doesn't support rc6pp
This machine doesn't support rc6p
The residency counter : 0.987000
This machine entry rc6 state.
Subtest rc6-residency-counter: SUCCESS

root@x-bdw05:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# 
./pm_rc6_residency --run-subtest rc6-residency-check
IGT-Version: 1.6-g9a70e29 (x86_64) (Linux: 
3.15.0-rc7_drm-intel-nightly_0a37b5_20140604+ x86_64)
Subtest rc6-residency-check: SUCCESS

root@x-bdw05:/GFX/Test/Intel_gpu_tools/intel-gpu-tools/tests# 
./pm_rc6_residency --list
rc6-residency-check
rc6-residency-counter

Run as non-root
[haha@x-pk home]$ ./pm_rc6_residency
IGT-Version: 1.6-g18d2130 (x86_64) (Linux: 
3.13.0-rc3_drm-intel-nightly_639e4d_20131210+ x86_64)
No intel gpu found
Subtest rc6-residency-check: SKIP
Subtest rc6-residency-counter: SKIP

Run on non-intel platform
[root@x-pk5 home]# ./pm_rc6_residency
IGT-Version: 1.6-g18d2130 (x86_64) (Linux: 
3.13.0-rc3_drm-intel-nightly_639e4d_20131210+ x86_64)
Test requirement not met in function read_rc6_residency, file 
pm_rc6_residency.c:77:
Last errno: 2, No such file or directory
Test requirement: (!(file))
Subtest rc6-residency-check: SKIP
Subtest rc6-residency-counter: SKIP

Signed-off-by: Wendy Wang wendy.w...@intel.com

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index e4c23b3..214c055 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -72,6 +72,7 @@ TESTS_progs_M = \
pm_lpsp \
pm_rpm \
pm_rps \
+   pm_rc6_residency \
prime_self_import \
template \
$(NULL)
@@ -138,7 +139,6 @@ TESTS_progs = \
kms_sink_crc_basic \
kms_fence_pin_leak \
pm_psr \
-   pm_rc6_residency \
prime_udl \
$(NULL)
 
diff --git a/tests/pm_rc6_residency.c b/tests/pm_rc6_residency.c
index 550e3ad..d364369 100644
--- a/tests/pm_rc6_residency.c
+++ b/tests/pm_rc6_residency.c
@@ -38,7 +38,6 @@
 #define SLEEP_DURATION 3000 // in milliseconds
 #define RC6_FUDGE 900 // in milliseconds
 
-
 static unsigned int readit(const char *path)
 {
unsigned int ret;
@@ -60,6 +59,7 @@ static unsigned int readit(const char *path)
 
 static void read_rc6_residency( int value[], const char 
*name_of_rc6_residency[])
 {
+   unsigned int i;
const int device = drm_get_card();
char *path ;
int  ret;
@@ -72,32 +72,33 @@ static void read_rc6_residency( int value[], const char 
*name_of_rc6_residency[]
ret = asprintf(path, /sys/class/drm/card%d/power/rc6_enable, device);
igt_assert(ret != -1);
 
-   file = fopen(path, r);//open
+   file = fopen(path, r);
igt_require(file);
 
/* claim success if no rc6 enabled. */
if (readit(path) == 0)
igt_success();
 
-   for(unsigned int i = 0; i  6; i++)
+   for(i = 0; i  6; i++)
{
if(i == 3)
sleep(SLEEP_DURATION / 1000);
-   ret = asprintf(path, 
/sys/class/drm/card%d/power/%s_residency_ms,device,name_of_rc6_residency[i % 
3] );
+   ret = asprintf(path, 
/sys/class/drm/card%d/power/%s_residency_ms,device,name_of_rc6_residency[i % 
3]);
igt_assert(ret != -1);
value[i] = readit(path);
}
free(path);
 }
 
-static void rc6_residency_counter(int value[],const char * 
name_of_rc6_residency[])
+static void rc6_residency_counter(int value[],const char 
*name_of_rc6_residency[])
 {
+   int flag;
unsigned int flag_counter,flag_support;
-   double  counter_result = 0;
+   double counter_result = 0;
flag_counter = 0;
flag_support = 0;
 
-   for(int flag = NUMBER_OF_RC6_RESIDENCY-1; flag = 0 ; flag --)
+   for(flag = NUMBER_OF_RC6_RESIDENCY-1; flag = 0; flag --)
{
unsigned int  tmp_counter, tmp_support;
double counter;
@@ -124,11 +125,10 @@ static void rc6_residency_counter(int value[],const char 
* name_of_rc6_residency
flag_support = flag_support  1;
}
 
-   printf(The

Re: [Intel-gfx] [PATCH] drm/i915: Avoid double mutex lock applying pipe A quirk during sanitize_crtc()

2014-06-09 Thread Chris Wilson

On Mon, Jun 09, 2014 at 11:30:26AM +0300, Ville Syrjälä wrote:
 On Mon, Jun 09, 2014 at 07:47:10AM +0100, Chris Wilson wrote:
  Thomas found that his machine would deadlock reloading the i915.ko
  module after resume. He identified that this was caused by the
  reacquisition of the connection mutex inside intel_enable_pipe_a()
  during the CRTC sanitization routine. This will only affect machines
  that quirk PIPE A, i.e. the original 830m chipsets.
  
  This patch move the locking into a wrapper function so that
  intel_enable_pipe_a() can bypass the locking knowing that it already
  holds the correct locks.
 
 It can still try to grab crtc-mutex twice. Looks like Danial undid my
 fix to not take all the modeset locks around
 intel_modeset_setup_hw_state().

Oh well, I only considered the santize_crtc path as I thought we would
have caught the modeset sequence deadlocking earlier.

Anyway, the locking is in flux due to the conversion to ww_mutex.
Have fun ;-)
-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] 3.15-rc: regression in suspend

2014-06-09 Thread Daniel Vetter

On Sun, Jun 8, 2014 at 1:11 AM, Pavel Machek pa...@ucw.cz wrote:
 Strange. It seems 3.15 with the patch reverted only boots in 30% or so
 cases... And I've seen resume failure, too, so maybe I was just lucky
 that it worked for a while.

git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
the 5th report or so that claims this is the culprit but it's
something else. The above code is definitely not used in i915 so bogus
bisect result.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 3.15-rc: regression in suspend

2014-06-09 Thread Pavel Machek

On Mon 2014-06-09 11:25:20, Daniel Vetter wrote:
 On Sun, Jun 8, 2014 at 1:11 AM, Pavel Machek pa...@ucw.cz wrote:
  Strange. It seems 3.15 with the patch reverted only boots in 30% or so
  cases... And I've seen resume failure, too, so maybe I was just lucky
  that it worked for a while.
 
 git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
 the 5th report or so that claims this is the culprit but it's
 something else. The above code is definitely not used in i915 so bogus
 bisect result.

Note I did not do the bisect, I only attempted revert and test.

And did three boots of successful s2ram.. only to find out that it
does not really fix s2ram, I was just lucky :-(.

Unfortunately, this means my s2ram problem will be tricky/impossible
to bisect :-(.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Partial success - Fixing resume from s2ram on S6010


Hi Ville, dear intel experts,

without the deadlock in i915, I had at least a partial success in 
restoring the video on the Fujitsu S6010.
Apparently, the bios does not re-initialize the 830MG registers, nor the 
registers of the ns2501 DVO.
Instead, the 830MG is configured in a 640x480 mode (no matter what the 
suspend mode was) and
the DVO is configured in a DPMS off state (no matter what the mode was 
before the suspend).


The attached script, to be placed in /etc/pm/sleep.d/99video will force 
correct values back into the registers
and thus restore the display. Partially. Trouble still is that the 
restored screen has some type of hick-up by
moving left or right by a couple of pixels (probably exactly by one 
tile, I did not measure). Interestingly,
a dump of the DVO and 830MG registers did not reveal any significant 
difference before and after the restore,

so it is still unclear why that hick-up appears.

Anyhow - it seems that $OTHER_OS has a completely different strategy for 
resume than Linux. $OTHER_OS seems
to simply re-load the video registers for the currently active mode, 
ignoring the current state of the hardware.
The i915 kernel module instead seems to try to interpret the current 
register set to a video mode, and then
restores its state from the state of the hardware. It seems to me that 
this is a less than ideal approach, and
it would be better keep a copy of the registers how they should be 
during suspend, and restore them in
the kernel module to the correct video mode on resume, ignoring whatever 
the bios left there.


Do kernel modules like the i915 or the dvo_ns2501 offer some kind of 
hook that is called by the kernel when
the machine is suspended and resumed? If so, this would be extremely 
helpful and would allow a much safer
suspend/resume operation than currently possible with the mode-detect 
guess i915 attempts to do.


Thanks,
Thomas

#!/bin/sh
#
PATH=/root/bin/:$PATH

suspend_video()
{   
chvt 1
sleep 0.5
}

restore_video()
{
intel_reg_write 0x2120 0
intel_reg_write 0x61140 0x90004084
intel_reg_write 0x61100 0xC18
intel_reg_write 0x70180 0xd800
intel_reg_write 0x70188 0x2000
intel_reg_write 0x70190 0x02ff03ff
intel_reg_write 0x6001c 0x03ff02ff
intel_reg_write 0x70024 0x1207
intel_reg_write 0x06040 0x0004150d
intel_reg_write 0x06044 0x0004150d
intel_reg_write 0x6014 0xd082
intel_reg_write 0x6 0x053f03ff
intel_reg_write 0x60004 0x053f03ff
intel_reg_write 0x60008 0x049f0417
intel_reg_write 0x6000c 0x032502ff
intel_reg_write 0x60010 0x032502ff
intel_reg_write 0x60014 0x03080302
intel_reg_write 0x71180 0x0100
intel_reg_write 0x71008 0x8000
intel_reg_write 0x6101c 0x027f01df
intel_reg_write 0x71024 0x9206
intel_reg_write 0x06018 0xc08b
intel_reg_write 0x61000 0x031f027f
intel_reg_write 0x61004 0x03170287
intel_reg_write 0x61008 0x02ef028f
intel_reg_write 0x6100c 0x020c01df
intel_reg_write 0x61010 0x020401e7
intel_reg_write 0x61014 0x01eb01e9
intel_reg_write 0x2000 0x00400131
intel_reg_write 0x2004 0x05000561
intel_reg_write 0x200c 0x02000561
intel_reg_write 0x2010 0x0

modprobe i2c-hid
modprobe i2c-algo-bit
modprobe i2c-dev
modprobe i2c-scmi
modprobe i2c-i801
modprobe i2c-ismt
modprobe i2c-gpio
modprobe i2c-piix4
modprobe i2c-isch
modprobe i2c-mux
modprobe i2c-core

i2cset -y 5 0x38 8 0x35
i2cset -y 5 0x38 0x34 0x03
i2cset -y 5 0x38 0x35 0xff
i2cset -y 5 0x38 0x37 0x44
i2cset -y 5 0x38 0x40 0x80
i2cset -y 5 0x38 0x41 0x00
i2cset -y 5 0x38 0xb7 0x03
i2cset -y 5 0x38 0xc0 0x01
i2cset -y 5 0x38 0xf0 0xca
i2cset -y 5 0x38 0xf1 0x00
i2cset -y 5 0x38 0xf2 0x11

chvt 7
}

case $1 in
suspend) suspend_video;;
hibernate) suspend_video;;
resume) restore_video;;
thaw) restore_video;;
esac
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] 3.15-rc: regression in suspend

2014-06-09 Thread Jiri Kosina

On Mon, 9 Jun 2014, Pavel Machek wrote:

   Strange. It seems 3.15 with the patch reverted only boots in 30% or so
   cases... And I've seen resume failure, too, so maybe I was just lucky
   that it worked for a while.
  
  git bisect really likes 25f397a429dfa43f22c278d0119a60 - you're about
  the 5th report or so that claims this is the culprit but it's
  something else. The above code is definitely not used in i915 so bogus
  bisect result.
 
 Note I did not do the bisect, I only attempted revert and test.
 
 And did three boots of successful s2ram.. only to find out that it
 does not really fix s2ram, I was just lucky :-(.
 
 Unfortunately, this means my s2ram problem will be tricky/impossible
 to bisect :-(.

Welcome to the situation I have been in for past several months.

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

[Intel-gfx] [i-g-t 2/2] quick_dump: read the architecture files for items to add to EXTRA_DIST

2014-06-09 Thread Thomas Wood

Each architecture file contains a list of the text files it requires, so
use this to add to the list of files to distribute.

Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 configure.ac | 6 ++
 tools/quick_dump/Makefile.am | 9 +
 2 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/configure.ac b/configure.ac
index cb130a9..9c52188 100644
--- a/configure.ac
+++ b/configure.ac
@@ -203,6 +203,12 @@ fi
 AM_CONDITIONAL(BUILD_TESTS, [test x$BUILD_TESTS = xyes])
 AC_DEFINE_UNQUOTED(TARGET_CPU_PLATFORM, [$host_cpu], [Target platform])
 
+files=broadwell cherryview haswell ivybridge sandybridge valleyview
+for file in $files; do
+   QUICK_DUMP_EXTRA_DIST+=$file `tr '\n' ' '  tools/quick_dump/$file`
+done
+AC_SUBST(QUICK_DUMP_EXTRA_DIST)
+
 AC_CONFIG_FILES([
 Makefile
 benchmarks/Makefile
diff --git a/tools/quick_dump/Makefile.am b/tools/quick_dump/Makefile.am
index a7b2a16..2d1685b 100644
--- a/tools/quick_dump/Makefile.am
+++ b/tools/quick_dump/Makefile.am
@@ -23,15 +23,8 @@ all-local: I915ChipsetPython.la
$(LN_S) -f .libs/I915ChipsetPython.so _chipset.so
 
 CLEANFILES = chipset_wrap_python.c chipset.py _chipset.so
-EXTRA_DIST =  \
+EXTRA_DIST = $(QUICK_DUMP_EXTRA_DIST) \
  base_display.txt base_interrupt.txt base_other.txt base_power.txt 
base_rings.txt \
- gen6_other.txt sandybridge \
- gen7_other.txt ivybridge \
- vlv_pipe_a.txt vlv_pipe_b.txt \
- vlv_display_base.txt vlv_dpio_phy.txt \
- vlv_dsi.txt vlv_flisdsi.txt \
- valleyview \
- gen8_interrupt.txt \
  quick_dump.py \
  reg_access.py \
  chipset.i chipset.py
-- 
1.9.3

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

[Intel-gfx] [i-g-t 1/2] tools: fix distcheck

2014-06-09 Thread Thomas Wood

Fix include paths and references to missing files.

Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 tools/null_state_gen/Makefile.am  | 3 +++
 tools/null_state_gen/intel_renderstate_gen6.c | 4 ++--
 tools/null_state_gen/intel_renderstate_gen7.c | 4 ++--
 tools/null_state_gen/intel_renderstate_gen8.c | 4 ++--
 tools/quick_dump/Makefile.am  | 5 -
 5 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/tools/null_state_gen/Makefile.am b/tools/null_state_gen/Makefile.am
index 62b8ff7..c0103a0 100644
--- a/tools/null_state_gen/Makefile.am
+++ b/tools/null_state_gen/Makefile.am
@@ -1,7 +1,10 @@
 noinst_PROGRAMS = intel_null_state_gen
 
+AM_CFLAGS = -I$(top_srcdir) -I$(top_srcdir)/lib
+
 intel_null_state_gen_SOURCES = \
intel_batchbuffer.c \
+   intel_batchbuffer.h \
intel_renderstate_gen6.c \
intel_renderstate_gen7.c \
intel_renderstate_gen8.c \
diff --git a/tools/null_state_gen/intel_renderstate_gen6.c 
b/tools/null_state_gen/intel_renderstate_gen6.c
index f169d02..dc255cf 100644
--- a/tools/null_state_gen/intel_renderstate_gen6.c
+++ b/tools/null_state_gen/intel_renderstate_gen6.c
@@ -1,6 +1,6 @@
 #include intel_batchbuffer.h
-#include lib/gen6_render.h
-#include lib/intel_reg.h
+#include gen6_render.h
+#include intel_reg.h
 #include string.h
 
 static const uint32_t ps_kernel_nomask_affine[][4] = {
diff --git a/tools/null_state_gen/intel_renderstate_gen7.c 
b/tools/null_state_gen/intel_renderstate_gen7.c
index 8fe8a80..4f955c3 100644
--- a/tools/null_state_gen/intel_renderstate_gen7.c
+++ b/tools/null_state_gen/intel_renderstate_gen7.c
@@ -23,8 +23,8 @@
 
 
 #include intel_batchbuffer.h
-#include lib/gen7_render.h
-#include lib/intel_reg.h
+#include gen7_render.h
+#include intel_reg.h
 #include stdio.h
 
 static const uint32_t ps_kernel[][4] = {
diff --git a/tools/null_state_gen/intel_renderstate_gen8.c 
b/tools/null_state_gen/intel_renderstate_gen8.c
index 437454e..b922c73 100644
--- a/tools/null_state_gen/intel_renderstate_gen8.c
+++ b/tools/null_state_gen/intel_renderstate_gen8.c
@@ -1,6 +1,6 @@
 #include intel_batchbuffer.h
-#include lib/gen8_render.h
-#include lib/intel_reg.h
+#include gen8_render.h
+#include intel_reg.h
 #include string.h
 
 struct {
diff --git a/tools/quick_dump/Makefile.am b/tools/quick_dump/Makefile.am
index 468dd45..a7b2a16 100644
--- a/tools/quick_dump/Makefile.am
+++ b/tools/quick_dump/Makefile.am
@@ -27,7 +27,10 @@ EXTRA_DIST =  \
  base_display.txt base_interrupt.txt base_other.txt base_power.txt 
base_rings.txt \
  gen6_other.txt sandybridge \
  gen7_other.txt ivybridge \
- vlv_display.txt vlv_dpio.txt valleyview \
+ vlv_pipe_a.txt vlv_pipe_b.txt \
+ vlv_display_base.txt vlv_dpio_phy.txt \
+ vlv_dsi.txt vlv_flisdsi.txt \
+ valleyview \
  gen8_interrupt.txt \
  quick_dump.py \
  reg_access.py \
-- 
1.9.3

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

Re: [Intel-gfx] Partial success - Fixing resume from s2ram on S6010

On Mon, Jun 09, 2014 at 12:57:46PM +0200, Thomas Richter wrote:
 Hi Ville, dear intel experts,
 
 without the deadlock in i915, I had at least a partial success in 
 restoring the video on the Fujitsu S6010.
 Apparently, the bios does not re-initialize the 830MG registers, nor the 
 registers of the ns2501 DVO.
 Instead, the 830MG is configured in a 640x480 mode (no matter what the 
 suspend mode was) and
 the DVO is configured in a DPMS off state (no matter what the mode was 
 before the suspend).
 
 The attached script, to be placed in /etc/pm/sleep.d/99video will force 
 correct values back into the registers
 and thus restore the display. Partially. Trouble still is that the 
 restored screen has some type of hick-up by
 moving left or right by a couple of pixels (probably exactly by one 
 tile, I did not measure). Interestingly,
 a dump of the DVO and 830MG registers did not reveal any significant 
 difference before and after the restore,
 so it is still unclear why that hick-up appears.
 
 Anyhow - it seems that $OTHER_OS has a completely different strategy for 
 resume than Linux. $OTHER_OS seems
 to simply re-load the video registers for the currently active mode, 
 ignoring the current state of the hardware.
 The i915 kernel module instead seems to try to interpret the current 
 register set to a video mode, and then
 restores its state from the state of the hardware.

No, we do restore the mode you were using before suspend.

Are you still using vbetool? That would explain why things go bad since
vbetool will clobber whatever i915 already did.

-- 
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] Partial success - Fixing resume from s2ram on S6010


Am 09.06.2014 13:08, schrieb Ville Syrjälä

No, we do restore the mode you were using before suspend.

Are you still using vbetool? That would explain why things go bad since
vbetool will clobber whatever i915 already did.


No, vbetool is out of the equation (see the script attached to the 
previous post). However, I dumped the 830MG register set
and the ns2501 DVO set before and after the suspend, and they are pretty 
different. As said, the 830 is configured

to use a 640x480 mode (instead of the 1024x786 mode) and the DVO is off.

Maybe the kernel tries to mode-detect the connected monitor, and this 
fails because the PLLs are not yet
configured correctly? Note that the ns2501 requires a correctly 
configured DVO to be able to respond on
the i2c bus. If so, mode-detection requires configuring the PLLs to 
*some* useful mode before attempting

to detect anything, otherwise the DVO just plays dead.

Greetings,
Thomas

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

Re: [Intel-gfx] Partial success - Fixing resume from s2ram on S6010

On Mon, Jun 09, 2014 at 01:19:46PM +0200, Thomas Richter wrote:
 Am 09.06.2014 13:08, schrieb Ville Syrjälä
  No, we do restore the mode you were using before suspend.
 
  Are you still using vbetool? That would explain why things go bad since
  vbetool will clobber whatever i915 already did.
 
 No, vbetool is out of the equation (see the script attached to the 
 previous post).

So now you're using acpi_sleep=s3_bios, or nothing?

 However, I dumped the 830MG register set
 and the ns2501 DVO set before and after the suspend, and they are pretty 
 different. As said, the 830 is configured
 to use a 640x480 mode (instead of the 1024x786 mode) and the DVO is off.
 
 Maybe the kernel tries to mode-detect the connected monitor, and this 
 fails because the PLLs are not yet
 configured correctly? Note that the ns2501 requires a correctly 
 configured DVO to be able to respond on
 the i2c bus. If so, mode-detection requires configuring the PLLs to 
 *some* useful mode before attempting
 to detect anything, otherwise the DVO just plays dead.

Boot with drm.debug=0xe grab the dmesg after the resume and let's see
if there is something fishy happening.

-- 
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: Fix VLV CRC reading.

On Thu, Jun 05, 2014 at 02:28:17PM -0700, Rodrigo Vivi wrote:
 Adding missing Display mmio reg offset.
 
 Credits-to: Laws, Philip philip.l...@intel.com
 Cc: He, Shuang shuang...@intel.com
 Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

 ---
  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 286f05c..05e2541 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -2627,7 +2627,7 @@ enum punit_power_well {
  
  #define PORT_DFT_I9XX0x61150
  #define   DC_BALANCE_RESET   (1  25)
 -#define PORT_DFT2_G4X0x61154
 +#define PORT_DFT2_G4X(dev_priv-info.display_mmio_offset + 
 0x61154)
  #define   DC_BALANCE_RESET_VLV   (1  31)
  #define   PIPE_SCRAMBLE_RESET_MASK   (0x3  0)
  #define   PIPE_B_SCRAMBLE_RESET  (1  1)
 -- 
 1.9.3
 
 ___
 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

Re: [Intel-gfx] [Intel 945] BSM: How to determine size of DRAM used for internal graphics?

2014-06-09 Thread Paul Menzel

Dear Intel graphics folks,

Am Freitag, den 30.05.2014, 14:47 +0200 schrieb Paul Menzel:

Am Freitag, den 30.05.2014, 13:45 +0200 schrieb Paul Menzel:

since commit 17fec8a0 [1]

drm/i915: Use Graphics Base of Stolen Memory on all gen3+

Linux reads the register BSM (Base of Stolen Memory) directly to get the
base address of graphics stolen memory. With coreboot [2] and native
graphics init – note that everything works with the proprietary VGA
BIOS/Option ROM – this causes a regression [3] as this register is not
programmed at all.

From the datasheet *Mobile Intel® 945 Express Chipset Family* [4] the
register BSM is described on page 290.

Graphics Stolen Memory and TSEG are within DRAM space defined
under TOLUD. From the top of low used DRAM, (G)MCH claims 1 to
64 MBs of DRAM for internal graphics if enabled.

This register contains bits 31 to 20 of the base address of
stolen
DRAM memory. The host interface determines the base of
graphics stolen memory by subtracting the graphics stolen
memory size from TOLUD. See Device 0 TOLUD for more
explanations.

Also see Figure 12 *Main Memory Address Range* in section 9.2 on page
325.

Unfortunately I am unable to find out how the graphics stolen memory
size is determined. I’d have thought it is used for the framebuffer, but
according to page 93 (Graphics Mode select (GMS)) that the framebuffer
size can only be 1 MB or 8 MB, which contradicts that it can be up to 64
MB.

If it is determined implicitly by the value I set the BSM to, where can
I find the recommendations what size to use? I’d guess it is dependent
on the RAM size, that means dependent if the system has 512 MB or 4 GB
for example.

The datasheet documents the bits of the register BSM as Read Only (RO).
So I am even more confused now.

It turned out that the register is indeed read-only and that the
register to look at seems to be PGTBL_CTL/PGETBL_CTL.

Thanks,

Paul

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=17fec8a08698bcab98788e1e89f5b8e7502ababd
[2] http://www.coreboot.org/
[3] https://bugs.freedesktop.org/show_bug.cgi?id=79038
[4]
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/mobile-945-express-chipset-datasheet.pdf
Document Number: 309219-006

signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Partial success - Fixing resume from s2ram on S6010


Am 09.06.2014 13:31, schrieb Ville Syrjälä:



So now you're using acpi_sleep=s3_bios, or nothing?


Ok, tried now with acpi_sleep=s3. Unfortunately, this hangs the machine 
completely during resume, I cannot even ping it.


Then, I tried the same trick again, namely unloading the i915 module 
before the resume, reloading it after the resume. This worked 
flawlessly, display came back without requiring any quirks, even with 
the state the bios left the hardware in.


Note again that this is different for the resume from acpi_sleep=s3 or 
'nothing', where I can restore the display (though the result is a hick-up).


If there is another deadlock in i915 (not unlikely) I cannot debug it 
this way, unfortunately.


Unfortunately, the S6010 does not have a serial port to redirect the 
console to. I can only use the netconsole, though this reveals nothing. 
Probably the deadlock happens before the is enabled.


Greetings,
Thomas

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check for a stalled page flip after each vblank

On Fri, May 30, 2014 at 05:16:34PM +0100, Chris Wilson wrote:
 Long ago, back in the racy haydays of 915gm interrupt handling, page
 flips would occasionally go astray and leave the hardware stuck, and the
 display not updating. This annoyed people who relied on their systems
 being able to display continuously updating information 24/7, and so
 some code to detect when the driver missed the page flip completion
 signal was added. Until recently, it was presumed that the interrupt
 handling was now flawless, but once again Simon Farnsworth has found a
 system whose display will stall. Reinstate the pageflip stall detection,
 which works by checking to see if the hardware has been updated to the
 new framebuffer address following each vblank. If the hardware is
 scanning out from the new framebuffer, but we still think the flip is
 pending, then we kick our driver into submision.
 
 This is a continuation of the effort started with
 commit 4e5359cd053bfb7d8dabe4a63624a5726848ffbc
 Author: Simon Farnsworth simon.farnswo...@onelan.co.uk
 Date:   Wed Sep 1 17:47:52 2010 +0100
 
 drm/i915: Avoid pageflipping freeze when we miss the flip prepare 
 interrupt
 
 This now includes a belt-and-braces approach to make sure the driver
 (or the hardware) doesn't miss an interrupt and cause us to stop
 updating the display should the unthinkable happen and the pageflip fail - 
 i.e.
 that the user is able to continue submitting flips.
 
 Reported-by: Simon Farnsworth si...@farnz.org.uk
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75502
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 ---
  drivers/gpu/drm/i915/i915_debugfs.c  |  33 ---
  drivers/gpu/drm/i915/i915_irq.c  |  85 ---
  drivers/gpu/drm/i915/intel_display.c | 109 
 ++-
  drivers/gpu/drm/i915/intel_drv.h |   2 +
  4 files changed, 144 insertions(+), 85 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index 0b063c03d188..a05a33ab4b33 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -581,6 +581,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
 void *data)
  {
   struct drm_info_node *node = m-private;
   struct drm_device *dev = node-minor-dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
   unsigned long flags;
   struct intel_crtc *crtc;
  
 @@ -602,23 +603,37 @@ static int i915_gem_pageflip_info(struct seq_file *m, 
 void *data)
   seq_printf(m, Flip pending (waiting for vsync) 
 on pipe %c (plane %c)\n,
  pipe, plane);
   }
 + seq_printf(m, Flip queued on frame %d, now %d\n,
 +work-sbc, 
 atomic_read(dev-vblank[crtc-pipe].count));
   if (work-enable_stall_check)
   seq_puts(m, Stall check enabled, );
   else
   seq_puts(m, Stall check waiting for page flip 
 ioctl, );
   seq_printf(m, %d prepares\n, 
 atomic_read(work-pending));
  
 - if (work-old_fb_obj) {
 - struct drm_i915_gem_object *obj = 
 work-old_fb_obj;
 - if (obj)
 - seq_printf(m, Old framebuffer 
 gtt_offset 0x%08lx\n,
 -
 i915_gem_obj_ggtt_offset(obj));
 + {
 + u32 addr;
 +
 + if (INTEL_INFO(dev)-gen = 4)
 + addr = DSPSURF(crtc-plane);
 + else
 + addr = DSPADDR(crtc-plane);
 +
 + seq_printf(m, Current scanout address 
 0x%08x\n, 
 +I915_READ(addr));

current makes me think of the live address. But right now I can't think of a
better term to use there.

   }

I don't like the extra {} block. Such things always give me an
impression that this is a debug hack someone forgot to remove.

 +
   if (work-pending_flip_obj) {
 - struct drm_i915_gem_object *obj = 
 work-pending_flip_obj;
 - if (obj)
 - seq_printf(m, New framebuffer 
 gtt_offset 0x%08lx\n,
 -
 i915_gem_obj_ggtt_offset(obj));
 + bool complete;
 +
 + seq_printf(m, New framebuffer address 
 0x%08lx\n, (long)work-gtt_offset);
 +
 + if (INTEL_INFO(dev)-gen = 4)
 + complete = 
 I915_HI_DISPBASE(I915_READ(DSPSURF(crtc-plane))) == work-gtt_offset;
 +

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Decouple the stuck pageflip on modeset

On Fri, May 30, 2014 at 05:16:35PM +0100, Chris Wilson wrote:
 If we successfully confuse the hardware, and cause it to drop a queued
 pageflip, we wait for 60s and issue a warning before continuing on with
 the modeset. However, this leaves the pending pageflip still stuck
 indefinitely. Pretend to userspace that it does complete, and let us
 start afresh following the modeset.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: Ville Syrjälä ville.syrj...@linux.intel.com
 ---
  drivers/gpu/drm/i915/intel_display.c | 18 +++---
  1 file changed, 15 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 764b277e5937..54b69838e2de 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -3329,9 +3329,21 @@ void intel_crtc_wait_for_pending_flips(struct drm_crtc 
 *crtc)
  
   WARN_ON(waitqueue_active(dev_priv-pending_flip_queue));
  
 - WARN_ON(wait_event_timeout(dev_priv-pending_flip_queue,
 -!intel_crtc_has_pending_flip(crtc),
 -60*HZ) == 0);
 + if (WARN_ON(wait_event_timeout(dev_priv-pending_flip_queue,
 +!intel_crtc_has_pending_flip(crtc),
 +60*HZ) == 0)) {
 + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 + unsigned long flags;
 +
 + spin_lock_irqsave(dev-event_lock, flags);
 + if (intel_crtc-unpin_work) {
 + WARN_ONCE(1, Removing stuck page flip\n);
 + drm_vblank_put(dev, intel_crtc-pipe);
 + page_flip_completed(dev_priv, intel_crtc, 
 intel_crtc-unpin_work);
 + intel_crtc-unpin_work = NULL;
 + }
 + spin_unlock_irqrestore(dev-event_lock, flags);
 + }

Seems like a decent idea.

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

Though my comment (to the other patch) about moving drm_vblank_put()
into page_flip_completed() still seems valid.

  
   mutex_lock(dev-struct_mutex);
   intel_finish_fb(crtc-primary-fb);
 -- 
 2.0.0.rc4

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

[Intel-gfx] [PATCH] drm/i915: Avoid div-by-zero when pixel_multiplier is zero

2014-06-09 Thread ville . syrjala

From: Ville Syrjälä ville.syrj...@linux.intel.com

On certain platforms pixel_multiplier is read out in
.get_pipe_config(), but it also gets used to calculate the
pixel clock in intel_sdvo_get_config(). If the pipe is disable
but some SDVO outputs are active, we may end up dividing by zero
in intel_sdvo_get_config().

To avoid the problem simply check for zero pixel_multiplier and skip
the division. Another attempt at fixing this involved populating
pixel_multiplier to 1 even for disabled pipes, but that triggered a
WARN because SDVO_CMD_GET_CLOCK_RATE_MULT command failed and thus
encoder_pixel_multiplier was left at zero and didn't match
pipe_config-pixel_multiplier.

The divide by pixel_multiplier operation got introduced here:
 commit 18442d08786472c63a0a80c27f92b033dffc26de
 Author: Ville SyrjÃ¤lÃ¤ ville.syrj...@linux.intel.com
 Date:   Fri Sep 13 16:00:08 2013 +0300

drm/i915: Fix port_clock and adjusted_mode.clock readout all over

and it has caused a regression on certain machines since they would
hit the div-by-zero during resume.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76520
Cc: sta...@vger.kernel.org # 3.13+
Tested-by: Tim Richardson t...@tim-richardson.net
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/intel_sdvo.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 6a4d5bc..20375cc 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1385,7 +1385,9 @@ static void intel_sdvo_get_config(struct intel_encoder 
*encoder,
  SDVO_PORT_MULTIPLY_SHIFT) + 1;
}
 
-   dotclock = pipe_config-port_clock / pipe_config-pixel_multiplier;
+   dotclock = pipe_config-port_clock;
+   if (pipe_config-pixel_multiplier)
+   dotclock /= pipe_config-pixel_multiplier;
 
if (HAS_PCH_SPLIT(dev))
ironlake_check_encoder_dotclock(pipe_config, dotclock);
-- 
1.8.5.5

___
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: Kick out vga console

2014-06-09 Thread Tomi Valkeinen

Hi,

On 06/06/14 18:20, Daniel Vetter wrote:
 Tomi/Jean can you please ack merging this through drm-intel trees? It
 just exports the vga and dummy consoles so that i915 can do what it
 needs to do.

Acked-by: Tomi Valkeinen tomi.valkei...@ti.com

 Tomi




signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm: Driver-specific ioctls range from 0x40 to 0x9f

DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.

Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 include/uapi/drm/drm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 9abbeb9..b0b8556 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -780,7 +780,7 @@ struct drm_prime_handle {
 
 /**
  * Device specific ioctls should only be in their respective headers
- * The device specific ioctl range is from 0x40 to 0x99.
+ * The device specific ioctl range is from 0x40 to 0x9f.
  * Generic IOCTLS restart at 0xA0.
  *
  * \sa drmCommandNone(), drmCommandRead(), drmCommandWrite(), and
-- 
1.8.3.1

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

[Intel-gfx] [PATCH 3/3] drm/i915: Fix the confusing comment about the ioctl limits

It was reported that this comment was confusing, and indeed it is.

Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 include/uapi/drm/i915_drm.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ff57f07..eacd063 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -171,8 +171,12 @@ typedef struct _drm_i915_sarea {
 #define I915_BOX_TEXTURE_LOAD  0x8
 #define I915_BOX_LOST_CONTEXT  0x10
 
-/* I915 specific ioctls
- * The device specific ioctl range is 0x40 to 0x79.
+/*
+ * i915 specific ioctls.
+ *
+ * The device specific ioctl range is [DRM_COMMAND_BASE, DRM_COMMAND_END) ie
+ * [0x40, 0xa0) (a0 is excluded) and those defines are offsets from
+ * DRM_COMMAND_BASE.
  */
 #define DRM_I915_INIT  0x00
 #define DRM_I915_FLUSH 0x01
-- 
1.8.3.1

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

[Intel-gfx] [PATCH 1/3] drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()

I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
in a few places. I suspect its usage has been spread by copy  paste
rather than anything else.

Let's just remove it for plain ARRAY_SIZE().

Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 drivers/gpu/drm/armada/armada_drv.c | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
 drivers/gpu/drm/gma500/psb_drv.c| 2 +-
 drivers/gpu/drm/i810/i810_dma.c | 2 +-
 drivers/gpu/drm/i915/i915_dma.c | 2 +-
 drivers/gpu/drm/i915/i915_ioc32.c   | 2 +-
 drivers/gpu/drm/mga/mga_ioc32.c | 2 +-
 drivers/gpu/drm/mga/mga_state.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
 drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
 drivers/gpu/drm/r128/r128_ioc32.c   | 2 +-
 drivers/gpu/drm/r128/r128_state.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_ioc32.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
 drivers/gpu/drm/radeon/radeon_state.c   | 2 +-
 drivers/gpu/drm/savage/savage_bci.c | 2 +-
 drivers/gpu/drm/sis/sis_mm.c| 2 +-
 drivers/gpu/drm/via/via_dma.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
 include/drm/drmP.h  | 2 --
 20 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index 567cfbd..8ab3cd1 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -402,7 +402,7 @@ static struct platform_driver armada_drm_platform_driver = {
 
 static int __init armada_drm_init(void)
 {
-   armada_drm_driver.num_ioctls = DRM_ARRAY_SIZE(armada_ioctls);
+   armada_drm_driver.num_ioctls = ARRAY_SIZE(armada_ioctls);
return platform_driver_register(armada_drm_platform_driver);
 }
 module_init(armada_drm_init);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 87461d4..ddb5003 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -569,7 +569,7 @@ static int exynos_drm_platform_probe(struct platform_device 
*pdev)
int ret;
 
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
-   exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls);
+   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
 
 #ifdef CONFIG_DRM_EXYNOS_FIMD
ret = platform_driver_register(fimd_driver);
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 59ea45e..6e8fe9e 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -477,7 +477,7 @@ static struct drm_driver driver = {
.lastclose = psb_driver_lastclose,
.preclose = psb_driver_preclose,
 
-   .num_ioctls = DRM_ARRAY_SIZE(psb_ioctls),
+   .num_ioctls = ARRAY_SIZE(psb_ioctls),
.device_is_agp = psb_driver_device_is_agp,
.irq_preinstall = psb_irq_preinstall,
.irq_postinstall = psb_irq_postinstall,
diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index aeace37..e88bac1 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -1251,7 +1251,7 @@ const struct drm_ioctl_desc i810_ioctls[] = {
DRM_IOCTL_DEF_DRV(I810_FLIP, i810_flip_bufs, DRM_AUTH|DRM_UNLOCKED),
 };
 
-int i810_max_ioctl = DRM_ARRAY_SIZE(i810_ioctls);
+int i810_max_ioctl = ARRAY_SIZE(i810_ioctls);
 
 /**
  * Determine if the device really is AGP or not.
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 93c0e1a..7c63b18 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2025,7 +2025,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_UNLOCKED|DRM_RENDER_ALLOW),
 };
 
-int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
+int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);
 
 /*
  * This is really ugly: Because old userspace abused the linux agp interface to
diff --git a/drivers/gpu/drm/i915/i915_ioc32.c 
b/drivers/gpu/drm/i915/i915_ioc32.c
index 3c59584..2e0613e 100644
--- a/drivers/gpu/drm/i915/i915_ioc32.c
+++ b/drivers/gpu/drm/i915/i915_ioc32.c
@@ -208,7 +208,7 @@ long i915_compat_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
if (nr  DRM_COMMAND_BASE)
return drm_compat_ioctl(filp, cmd, arg);
 
-   if (nr  DRM_COMMAND_BASE + DRM_ARRAY_SIZE(i915_compat_ioctls))
+   if (nr  DRM_COMMAND_BASE + ARRAY_SIZE(i915_compat_ioctls))
fn = i915_compat_ioctls[nr - DRM_COMMAND_BASE];
 
if (fn != NULL)
diff --git a/drivers/gpu/drm/mga/mga_ioc32.c b/drivers/gpu/drm/mga/mga_ioc32.c
index 86b4bb8..729bfd5 100644
--- a/drivers/gpu/drm/mga/mga_ioc32.c
+++ b/drivers/gpu/drm/mga/mga_ioc32.c
@@ -214,7 +214,7 @@ long mga_compat_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
if (nr  DRM_COMMAND_BASE)

[Intel-gfx] [PATCH 0/3] A couple of fixes about the ioctl number split

It was reported a long time ago the various comments about the DRM/driver
specific ioctl split were confusing. So tried to fix that.

Patch #1 is a bonus patch that removes DRM_ARRAY_SIZE().

-- 
Damien

Damien Lespiau (3):
  drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()
  drm: Driver-specific ioctls range from 0x40 to 0x9f
  drm/i915: Fix the confusing comment about the ioctl limits

 drivers/gpu/drm/armada/armada_drv.c | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
 drivers/gpu/drm/gma500/psb_drv.c| 2 +-
 drivers/gpu/drm/i810/i810_dma.c | 2 +-
 drivers/gpu/drm/i915/i915_dma.c | 2 +-
 drivers/gpu/drm/i915/i915_ioc32.c   | 2 +-
 drivers/gpu/drm/mga/mga_ioc32.c | 2 +-
 drivers/gpu/drm/mga/mga_state.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
 drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
 drivers/gpu/drm/r128/r128_ioc32.c   | 2 +-
 drivers/gpu/drm/r128/r128_state.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_ioc32.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
 drivers/gpu/drm/radeon/radeon_state.c   | 2 +-
 drivers/gpu/drm/savage/savage_bci.c | 2 +-
 drivers/gpu/drm/sis/sis_mm.c| 2 +-
 drivers/gpu/drm/via/via_dma.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
 include/drm/drmP.h  | 2 --
 include/uapi/drm/drm.h  | 2 +-
 include/uapi/drm/i915_drm.h | 8 ++--
 22 files changed, 26 insertions(+), 24 deletions(-)

-- 
1.8.3.1

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

Re: [Intel-gfx] [PATCH 1/3] drm: Remove DRM_ARRAY_SIZE() for ARRAY_SIZE()

2014-06-09 Thread Alex Deucher

On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau damien.lesp...@intel.com wrote:
 I cannot see a need to provide a DRM_ version of ARRAY_SIZE(), only used
 in a few places. I suspect its usage has been spread by copy  paste
 rather than anything else.

 Let's just remove it for plain ARRAY_SIZE().

 Signed-off-by: Damien Lespiau damien.lesp...@intel.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  drivers/gpu/drm/armada/armada_drv.c | 2 +-
  drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
  drivers/gpu/drm/gma500/psb_drv.c| 2 +-
  drivers/gpu/drm/i810/i810_dma.c | 2 +-
  drivers/gpu/drm/i915/i915_dma.c | 2 +-
  drivers/gpu/drm/i915/i915_ioc32.c   | 2 +-
  drivers/gpu/drm/mga/mga_ioc32.c | 2 +-
  drivers/gpu/drm/mga/mga_state.c | 2 +-
  drivers/gpu/drm/nouveau/nouveau_ioc32.c | 2 +-
  drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-
  drivers/gpu/drm/r128/r128_ioc32.c   | 2 +-
  drivers/gpu/drm/r128/r128_state.c   | 2 +-
  drivers/gpu/drm/radeon/radeon_ioc32.c   | 2 +-
  drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
  drivers/gpu/drm/radeon/radeon_state.c   | 2 +-
  drivers/gpu/drm/savage/savage_bci.c | 2 +-
  drivers/gpu/drm/sis/sis_mm.c| 2 +-
  drivers/gpu/drm/via/via_dma.c   | 2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
  include/drm/drmP.h  | 2 --
  20 files changed, 19 insertions(+), 21 deletions(-)

 diff --git a/drivers/gpu/drm/armada/armada_drv.c 
 b/drivers/gpu/drm/armada/armada_drv.c
 index 567cfbd..8ab3cd1 100644
 --- a/drivers/gpu/drm/armada/armada_drv.c
 +++ b/drivers/gpu/drm/armada/armada_drv.c
 @@ -402,7 +402,7 @@ static struct platform_driver armada_drm_platform_driver 
 = {

  static int __init armada_drm_init(void)
  {
 -   armada_drm_driver.num_ioctls = DRM_ARRAY_SIZE(armada_ioctls);
 +   armada_drm_driver.num_ioctls = ARRAY_SIZE(armada_ioctls);
 return platform_driver_register(armada_drm_platform_driver);
  }
  module_init(armada_drm_init);
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index 87461d4..ddb5003 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -569,7 +569,7 @@ static int exynos_drm_platform_probe(struct 
 platform_device *pdev)
 int ret;

 pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
 -   exynos_drm_driver.num_ioctls = DRM_ARRAY_SIZE(exynos_ioctls);
 +   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);

  #ifdef CONFIG_DRM_EXYNOS_FIMD
 ret = platform_driver_register(fimd_driver);
 diff --git a/drivers/gpu/drm/gma500/psb_drv.c 
 b/drivers/gpu/drm/gma500/psb_drv.c
 index 59ea45e..6e8fe9e 100644
 --- a/drivers/gpu/drm/gma500/psb_drv.c
 +++ b/drivers/gpu/drm/gma500/psb_drv.c
 @@ -477,7 +477,7 @@ static struct drm_driver driver = {
 .lastclose = psb_driver_lastclose,
 .preclose = psb_driver_preclose,

 -   .num_ioctls = DRM_ARRAY_SIZE(psb_ioctls),
 +   .num_ioctls = ARRAY_SIZE(psb_ioctls),
 .device_is_agp = psb_driver_device_is_agp,
 .irq_preinstall = psb_irq_preinstall,
 .irq_postinstall = psb_irq_postinstall,
 diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
 index aeace37..e88bac1 100644
 --- a/drivers/gpu/drm/i810/i810_dma.c
 +++ b/drivers/gpu/drm/i810/i810_dma.c
 @@ -1251,7 +1251,7 @@ const struct drm_ioctl_desc i810_ioctls[] = {
 DRM_IOCTL_DEF_DRV(I810_FLIP, i810_flip_bufs, DRM_AUTH|DRM_UNLOCKED),
  };

 -int i810_max_ioctl = DRM_ARRAY_SIZE(i810_ioctls);
 +int i810_max_ioctl = ARRAY_SIZE(i810_ioctls);

  /**
   * Determine if the device really is AGP or not.
 diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
 index 93c0e1a..7c63b18 100644
 --- a/drivers/gpu/drm/i915/i915_dma.c
 +++ b/drivers/gpu/drm/i915/i915_dma.c
 @@ -2025,7 +2025,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
 DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
 DRM_UNLOCKED|DRM_RENDER_ALLOW),
  };

 -int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
 +int i915_max_ioctl = ARRAY_SIZE(i915_ioctls);

  /*
   * This is really ugly: Because old userspace abused the linux agp interface 
 to
 diff --git a/drivers/gpu/drm/i915/i915_ioc32.c 
 b/drivers/gpu/drm/i915/i915_ioc32.c
 index 3c59584..2e0613e 100644
 --- a/drivers/gpu/drm/i915/i915_ioc32.c
 +++ b/drivers/gpu/drm/i915/i915_ioc32.c
 @@ -208,7 +208,7 @@ long i915_compat_ioctl(struct file *filp, unsigned int 
 cmd, unsigned long arg)
 if (nr  DRM_COMMAND_BASE)
 return drm_compat_ioctl(filp, cmd, arg);

 -   if (nr  DRM_COMMAND_BASE + DRM_ARRAY_SIZE(i915_compat_ioctls))
 +   if (nr  DRM_COMMAND_BASE + ARRAY_SIZE(i915_compat_ioctls))
 fn = i915_compat_ioctls[nr - DRM_COMMAND_BASE];

 if (fn != NULL)
 diff --git a/drivers/gpu/drm/mga/mga_ioc32.c b/drivers/gpu/drm/mga/mga_ioc32.c
 index

Re: [Intel-gfx] [PATCH 2/3] drm: Driver-specific ioctls range from 0x40 to 0x9f

2014-06-09 Thread Alex Deucher

On Mon, Jun 9, 2014 at 9:39 AM, Damien Lespiau damien.lesp...@intel.com wrote:
 DRM_COMMAND_END is 0xa0, so the last driver ioctl is 0x9f, not 0x99.

 Signed-off-by: Damien Lespiau damien.lesp...@intel.com

Reviewed-by: Alex Deucher alexander.deuc...@amd.com

 ---
  include/uapi/drm/drm.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
 index 9abbeb9..b0b8556 100644
 --- a/include/uapi/drm/drm.h
 +++ b/include/uapi/drm/drm.h
 @@ -780,7 +780,7 @@ struct drm_prime_handle {

  /**
   * Device specific ioctls should only be in their respective headers
 - * The device specific ioctl range is from 0x40 to 0x99.
 + * The device specific ioctl range is from 0x40 to 0x9f.
   * Generic IOCTLS restart at 0xA0.
   *
   * \sa drmCommandNone(), drmCommandRead(), drmCommandWrite(), and
 --
 1.8.3.1

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

Re: [Intel-gfx] [PATCH v2 07/16] drm/i915: Add vblank based delayed watermark update mechanism

On Wed, Jun 04, 2014 at 06:10:44PM +0200, Daniel Vetter wrote:
 On Wed, Jun 04, 2014 at 11:01:01AM -0300, Paulo Zanoni wrote:
   This function is only called at init/resume. It populates the software
   state with something that matches the current hardware state. I guess
   a comment explaning the purpose of the function is the best we can do
   here, or do you have a better idea?
  
  The problem is that we can use the get_hw_state functions not only to
  check driver state a init/resume, but also to do state tracking
  assertions at certain points of the code. Since most (all?) the other
  HW state readout functions don't have side-effects, there's a
  possibility that someone may add code to do HW state assertion at some
  points, and just call these things without realizing the potential
  side effects. A comment would help, but moving the assignment to
  another place would also solve the problem for me. You choose.
 
 We already do that in other places, e.g. the edp bit depth hacks we have.
 But a comment might be justified.
 
 I haven't looked at the details here, just a high-level comment that we do
 play such ugly tricks already. And I agree that it's unexpected.

Well IIRC I didn't even call this function get_hw_state() until
someone asked me to rename it ;) I could rename it back to whatever
it was originally. It was never meant to be just a read hardware state
into a temp structure type of thing since it's been updating
intel_crtc-wm.active from the start.

With the rename I should be able to drop the ugly underscore from
_ilk_wm_get_hw_state().

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

[Intel-gfx] [PATCH] drm/i915: set backlight duty cycle after backlight enable for gen4

2014-06-09 Thread Jani Nikula

For reasons I can't claim to fully understand gen4 seems to require
backlight duty cycle setting after the backlight has been enabled, or
else black screen follows. I don't have documentation for the correct
sequence on gen4 either. Confirmed on Dell Latitude D630 and MacBook4,1.

This fixes a regression introduced by
commit b35684b8fa94e04f55fd38bf672b737741d2f9e2
Author: Jani Nikula jani.nik...@intel.com
Date:   Thu Nov 14 12:13:41 2013 +0200

drm/i915: do full backlight setup at enable time

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75791
Reported-and-tested-by: m...@lm7.fr
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79423
Reported-and-tested-by: Marc Milgram mmilg...@redhat.com
Cc: Stable sta...@vger.kernel.org # 3.14+
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/intel_panel.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 5e6c888b4928..38a98570d10c 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -798,9 +798,6 @@ static void i965_enable_backlight(struct intel_connector 
*connector)
ctl = freq  16;
I915_WRITE(BLC_PWM_CTL, ctl);
 
-   /* XXX: combine this into above write? */
-   intel_panel_actually_set_backlight(connector, panel-backlight.level);
-
ctl2 = BLM_PIPE(pipe);
if (panel-backlight.combination_mode)
ctl2 |= BLM_COMBINATION_MODE;
@@ -809,6 +806,8 @@ static void i965_enable_backlight(struct intel_connector 
*connector)
I915_WRITE(BLC_PWM_CTL2, ctl2);
POSTING_READ(BLC_PWM_CTL2);
I915_WRITE(BLC_PWM_CTL2, ctl2 | BLM_PWM_ENABLE);
+
+   intel_panel_actually_set_backlight(connector, panel-backlight.level);
 }
 
 static void vlv_enable_backlight(struct intel_connector *connector)
-- 
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/16] drm/i915: Disable LP1+ watermarks while changing the number of active pipes

On Wed, Jun 04, 2014 at 03:24:13PM -0300, Paulo Zanoni wrote:
 2014-05-22 11:48 GMT-03:00  ville.syrj...@linux.intel.com:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
 
  When we switch between one active pipe and multiple active pipes, the
  display FIFO gets repartitioned. Disable the LP1+ waterwarks while that
  is happening to make sure we don't get any glitches on other active
  pipes while doing a modeset on another other pipe.
 
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
  ---
   drivers/gpu/drm/i915/intel_display.c | 45 
  ++
   drivers/gpu/drm/i915/intel_drv.h |  2 ++
   drivers/gpu/drm/i915/intel_pm.c  | 47 
  
   3 files changed, 89 insertions(+), 5 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index bccf414..311c0f0 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -3985,6 +3985,27 @@ static struct intel_crtc 
  *get_other_active_crtc(struct intel_crtc *crtc)
  return other_active_crtc;
   }
 
  +static void ilk_prepare_for_num_pipes_change(struct intel_crtc *crtc)
  +{
  +   struct drm_device *dev = crtc-base.dev;
  +   struct intel_crtc *other_active_crtc = get_other_active_crtc(crtc);
  +
  +   /*
  +* If we change between one pipe and multiple pipes,
  +* make sure the other active pipe is prepared
  +* for having its FIFO resized. We do that by making
  +* sure the pipe isn't using LP1+ watermarks when
  +* the second pipe gets enabled or disabled.
  +*/
  +   if (!other_active_crtc)
  +   return;
 
 But get_other_active_crtc() returns NULL in case 2 other CRTCs are
 already active. If we're the third pipe being enabled, we may still
 get an underrun.

The FIFO repartitioning happens only when going 1-2 pipes, so the
2-3 cases don't matter here.

 
  +
  +   ilk_wm_synchronize(other_active_crtc);
  +
  +   if (ilk_disable_lp_wm(dev))
  +   intel_wait_for_vblank(dev, other_active_crtc-pipe);
  +}
  +
   static void ironlake_crtc_enable(struct drm_crtc *crtc)
   {
  struct drm_device *dev = crtc-dev;
  @@ -4023,6 +4044,9 @@ static void ironlake_crtc_enable(struct drm_crtc 
  *crtc)
 
  intel_crtc-active = true;
 
  +   /* Make sure other pipes are prepared for FIFO resizing */
  +   ilk_prepare_for_num_pipes_change(intel_crtc);
  +
  intel_set_cpu_fifo_underrun_reporting(dev, pipe, true);
  intel_set_pch_fifo_underrun_reporting(dev, pipe, true);
 
  @@ -4123,6 +4147,9 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
 
  intel_crtc-active = true;
 
  +   /* Make sure other pipes are prepared for FIFO resizing */
  +   ilk_prepare_for_num_pipes_change(intel_crtc);
  +
  intel_set_cpu_fifo_underrun_reporting(dev, pipe, true);
  if (intel_crtc-config.has_pch_encoder)
  intel_set_pch_fifo_underrun_reporting(dev, TRANSCODER_A, 
  true);
  @@ -4192,6 +4219,9 @@ static void ironlake_crtc_disable(struct drm_crtc 
  *crtc)
 
  intel_crtc_disable_planes(crtc);
 
  +   /* Make sure other pipes are prepared for FIFO resizing */
  +   ilk_prepare_for_num_pipes_change(intel_crtc);
  +
  for_each_encoder_on_crtc(dev, crtc, encoder)
  encoder-disable(encoder);
 
  @@ -4235,6 +4265,12 @@ static void ironlake_crtc_disable(struct drm_crtc 
  *crtc)
 
  intel_crtc-active = false;
 
  +   /*
  +* Potentially let some other pipe use the
  +* full FIFO, and re-enable LP1+ watermarks.
  +*/
  +   ilk_wm_pipe_post_disable(intel_crtc);
  +
  mutex_lock(dev-struct_mutex);
  intel_update_fbc(dev);
  intel_edp_psr_update(dev);
  @@ -4255,6 +4291,9 @@ static void haswell_crtc_disable(struct drm_crtc 
  *crtc)
 
  intel_crtc_disable_planes(crtc);
 
  +   /* Make sure other pipes are prepared for FIFO resizing */
  +   ilk_prepare_for_num_pipes_change(intel_crtc);
  +
  for_each_encoder_on_crtc(dev, crtc, encoder) {
  intel_opregion_notify_encoder(encoder, false);
  encoder-disable(encoder);
  @@ -4282,6 +4321,12 @@ static void haswell_crtc_disable(struct drm_crtc 
  *crtc)
 
  intel_crtc-active = false;
 
  +   /*
  +* Potentially let some other pipe use the
  +* full FIFO, and re-enable LP1+ watermarks.
  +*/
  +   ilk_wm_pipe_post_disable(intel_crtc);
  +
  mutex_lock(dev-struct_mutex);
  intel_update_fbc(dev);
  intel_edp_psr_update(dev);
  diff --git a/drivers/gpu/drm/i915/intel_drv.h 
  b/drivers/gpu/drm/i915/intel_drv.h
  index 5ad7ad5..98f878f 100644
  --- a/drivers/gpu/drm/i915/intel_drv.h
  +++ b/drivers/gpu/drm/i915/intel_drv.h
  @@ -1022,6 +1022,8 @@ void

Re: [Intel-gfx] [PATCH v2 08/16] drm/i915: Split watermark programming into pre and post steps

On Wed, Jun 04, 2014 at 06:22:13PM +0200, Daniel Vetter wrote:
 On Tue, Jun 03, 2014 at 05:51:01PM -0300, Paulo Zanoni wrote:
  2014-05-22 11:48 GMT-03:00  ville.syrj...@linux.intel.com:
   From: Ville Syrjälä ville.syrj...@linux.intel.com
  
   We need to perform watermark programming before and after changing the
   plane configuration. Add two new vfuncs to do that. The pre phase is
   supposed to switch over to the intermediate watermarks which are
   computed so that they can deal with both the old and new plane
   configurations. The post phase will arm the vblank based update
   systems to switch over to the optimal target watermarks after the
   plane configuration has for sure changed.
  
   v2: Pass around intel_crtc and s/intel_crtc/crtc/
  
   Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
   ---
drivers/gpu/drm/i915/i915_drv.h  |  5 +++
drivers/gpu/drm/i915/intel_drv.h | 11 +
drivers/gpu/drm/i915/intel_pm.c  | 88 
   
3 files changed, 104 insertions(+)
  
   diff --git a/drivers/gpu/drm/i915/i915_drv.h 
   b/drivers/gpu/drm/i915/i915_drv.h
   index c90d5ac..d4f8ae8 100644
   --- a/drivers/gpu/drm/i915/i915_drv.h
   +++ b/drivers/gpu/drm/i915/i915_drv.h
   @@ -407,6 +407,7 @@ struct intel_plane_config;
struct intel_crtc;
struct intel_limit;
struct dpll;
   +struct intel_crtc_wm_config;
  
struct drm_i915_display_funcs {
   bool (*fbc_enabled)(struct drm_device *dev);
   @@ -437,6 +438,10 @@ struct drm_i915_display_funcs {
struct drm_crtc *crtc,
uint32_t sprite_width, int pixel_size,
bool enable, bool scaled);
   +   void (*program_wm_pre)(struct intel_crtc *crtc,
   +  const struct intel_crtc_wm_config *config);
   +   void (*program_wm_post)(struct intel_crtc *crtc,
   +   const struct intel_crtc_wm_config 
   *config);
   void (*modeset_global_resources)(struct drm_device *dev);
   /* Returns the active state of the crtc, and if the crtc is 
   active,
* fills out the pipe-config with the hw state. */
   diff --git a/drivers/gpu/drm/i915/intel_drv.h 
   b/drivers/gpu/drm/i915/intel_drv.h
   index 72f01b1..4b59be3 100644
   --- a/drivers/gpu/drm/i915/intel_drv.h
   +++ b/drivers/gpu/drm/i915/intel_drv.h
   @@ -358,6 +358,13 @@ struct intel_pipe_wm {
   bool sprites_scaled;
};
  
   +struct intel_crtc_wm_config {
   +   /* target watermarks for the pipe */
   +   struct intel_pipe_wm target;
   +   /* intermediate watermarks for pending/active-target transition 
   */
   +   struct intel_pipe_wm intm;
  
  It seems you always prefer shorter names such as intm, and I usually
  prefer the longer ones like intermediate. Looks like this is a
  common topic for my bikesheddings on your patches. When I read intm
  my brain parses it as Int M and then aborts execution =P
 
 I agree with Paulo here. Some other name suggestion (since intermediate is
 so long): transition/transit, merged, pending, ...

The two good names I could think of intermediate and transitional
are both really long. I agree that intm is a horrible shorthand,
but I couldn't come up with anything half sane and still reasonably
short.

merged and pending already appear in the code with different
meaning, so I'd rather not confuse the matter by reusing those.
transition seems OK to me, though not that short either.
transit brings up wrong kinds of images in my brain so i don't
really like it.

 -Daniel
 
  
  With or without that changed: Reviewed-by: Paulo Zanoni
  paulo.r.zan...@intel.com
  
   +};
   +
struct intel_crtc {
   struct drm_crtc base;
   enum pipe pipe;
   @@ -1001,6 +1008,10 @@ void intel_init_runtime_pm(struct drm_i915_private 
   *dev_priv);
void intel_fini_runtime_pm(struct drm_i915_private *dev_priv);
void ilk_wm_get_hw_state(struct drm_device *dev);
void ilk_update_pipe_wm(struct drm_device *dev, enum pipe pipe);
   +void intel_program_watermarks_pre(struct intel_crtc *crtc,
   + const struct intel_crtc_wm_config 
   *config);
   +void intel_program_watermarks_post(struct intel_crtc *crtc,
   +  const struct intel_crtc_wm_config 
   *config);
  
  
/* intel_sdvo.c */
   diff --git a/drivers/gpu/drm/i915/intel_pm.c 
   b/drivers/gpu/drm/i915/intel_pm.c
   index 6fc6416..ccf920a 100644
   --- a/drivers/gpu/drm/i915/intel_pm.c
   +++ b/drivers/gpu/drm/i915/intel_pm.c
   @@ -2950,6 +2950,20 @@ void ilk_update_pipe_wm(struct drm_device *dev, 
   enum pipe pipe)
   spin_unlock(crtc-wm.lock);
}
  
   +static void ilk_wm_cancel(struct intel_crtc *crtc)
   +{
   +   struct drm_device *dev = crtc-base.dev;
   +
   +   assert_spin_locked(crtc-wm.lock);
   +
   +   crtc-wm.dirty =

[Intel-gfx] [PATCH] drm/i915/chv: WaDisablePwrmtrEvent:chv on CHV only

2014-06-09 Thread Tom . O'Rourke

From: Tom O'Rourke Tom.O'rou...@intel.com

In gen8_enable_rps, don't write CHV registers unless IS_CHERRYVIEW.

Signed-off-by: Tom O'Rourke Tom.O'rou...@intel.com
---
 drivers/gpu/drm/i915/intel_pm.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d9c5918..3d3e402 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3522,8 +3522,10 @@ static void gen8_enable_rps(struct drm_device *dev)
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
 
/* WaDisablePwrmtrEvent:chv (pre-production hw) */
-   I915_WRITE(0xA80C, I915_READ(0xA80C)  0x00ff);
-   I915_WRITE(0xA810, I915_READ(0xA810)  0xff00);
+   if (IS_CHERRYVIEW(dev)) {
+   I915_WRITE(0xA80C, I915_READ(0xA80C)  0x00ff);
+   I915_WRITE(0xA810, I915_READ(0xA810)  0xff00);
+   }
 
/* 5: Enable RPS */
I915_WRITE(GEN6_RP_CONTROL,
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH] drm/i915/chv: WaDisablePwrmtrEvent:chv on CHV only

On Mon, Jun 09, 2014 at 10:06:49AM -0700, Tom.O'rou...@intel.com wrote:
 From: Tom O'Rourke Tom.O'rou...@intel.com
 
 In gen8_enable_rps, don't write CHV registers unless IS_CHERRYVIEW.
 
 Signed-off-by: Tom O'Rourke Tom.O'rou...@intel.com

A lovely catch.

Reviewed-by: Damien Lespiau damien.lesp...@intel.com

-- 
Damien

 ---
  drivers/gpu/drm/i915/intel_pm.c |6 --
  1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index d9c5918..3d3e402 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -3522,8 +3522,10 @@ static void gen8_enable_rps(struct drm_device *dev)
   I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
  
   /* WaDisablePwrmtrEvent:chv (pre-production hw) */
 - I915_WRITE(0xA80C, I915_READ(0xA80C)  0x00ff);
 - I915_WRITE(0xA810, I915_READ(0xA810)  0xff00);
 + if (IS_CHERRYVIEW(dev)) {
 + I915_WRITE(0xA80C, I915_READ(0xA80C)  0x00ff);
 + I915_WRITE(0xA810, I915_READ(0xA810)  0xff00);
 + }
  
   /* 5: Enable RPS */
   I915_WRITE(GEN6_RP_CONTROL,
 -- 
 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] [PATCH] drm/i915: Disable FBC on Haswell

2014-06-09 Thread Jani Nikula

On Fri, 06 Jun 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
 It causes black screen on bootup and is approximately 100x slower than
 running with FBC disabled, so the GPU runs at a high frequency for much
 longer - completely contrary to the power saving claims. It also still
 has mutex deadlocks in multi-head scenarios, which can lead to a
 system/X lockup. These bugs were known before FBC was enabled by default
 on Haswell and still have not been fixed.

 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79716
 Reported-and-tested-by: Jon Kristensen i...@jonkri.com
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Cc: sta...@vger.kernel.org
 ---
  drivers/gpu/drm/i915/intel_pm.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index e403010540a5..0b8a6010427e 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -511,8 +511,7 @@ void intel_update_fbc(struct drm_device *dev)
   obj = intel_fb-obj;
   adjusted_mode = intel_crtc-config.adjusted_mode;
  
 - if (i915.enable_fbc  0 
 - INTEL_INFO(dev)-gen = 7  !IS_HASWELL(dev)) {
 + if (i915.enable_fbc  0) {

Not only does this disable FBC by default on Haswell but also on all
current and future platforms, including Broadwell. Shouldn't you leave
the INTEL_INFO(dev)-gen = 7 part intact?

BR,
Jani.


   if (set_no_fbc_reason(dev_priv, FBC_CHIP_DEFAULT))
   DRM_DEBUG_KMS(disabled per chip default\n);
   goto out_disable;
 -- 
 2.0.0

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

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

Re: [Intel-gfx] [PATCH v2 09/16] drm/i915: Actually perform the watermark update in two phases

On Tue, Jun 03, 2014 at 07:47:11PM -0300, Paulo Zanoni wrote:
 2014-05-22 11:48 GMT-03:00  ville.syrj...@linux.intel.com:
  From: Ville Syrjälä ville.syrj...@linux.intel.com
 
  Switch the code over to using the two phase watermark update. The steps
  generally follow this pattern:
 
  1. Calculate new plane parameters for changed planes
  2. Calculate new target and intermediate watermarks
  3. Check that both the target and intermediate watermarks are valid
  4. Program the hardware with the intermediate watermarks
  5. Program the plane registers
  6. Arm the vblank watermark update machinery for the next vblank
  7. Program the hardware with the target watermarks (after vblank)
 
  v2: Rebased, pass intel_crtc around, s/intel_crtc/crtc/
 
  Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
 
 This patch is huge. If we bisect any regression to it, we will be
 completely lost and hopeless. Also, my tiny little brain doesn't have
 enough power to do a proper review of this patch with so many changes
 happening all at the same place. I tried, but I gave up in the middle.
 
 Please try to convert this patch into many smaller patches. I don't
 know if the following idea is actually possible, but it is what I
 could extract from what I read of your patch:
 - I'd start with the way you update watermarks parameters. Start by
 patching ilk_compute_wm_parameters() and making it directly call your
 new update_xxx_params() functions. You can even do separate patches
 for _pri, _cur and _spr patches since it seems the _spr code is
 different for most of your patch due to the old
 intel_update_sprite_watermarks() function.
 - Then you change the way you use to set your parameters (there's a
 comment below mentioning the specific line which I'm talking about
 here)
 - Then you can patch intel_display.c so you will only update the WM
 params when you actually change the HW (the _hw_plane and
 update_cursor functions). Again, you can even split _pri, _cur and
 _spr on separate patches.
 - Then you can introduce the update_cursor_wm() and
 update_primary_wm() functions, but still make them call the old-style
 intel_update_watermarks() or something similar.
 - You can also add the functions to deal with intermediate watermarks,
 but without using them. Or you could, for example, make the
 intermediate watermarks just be the same as the old ones, so the
 only real update will be the final one (which, I believe, will mean
 the code still behaves as it does today, no regressions).
 - Then you can add the final piece of the code that uses all the new
 infrastructure to actually generate and use the intermediate
 watermarks. And this would be a much smaller patch.

I guess I can try to chunk it up more. But in that case I'll have to
make all the intermediate stages as impotent as possible since no one
will be testing them. So I fear it's going to be more patches that
essentially do nothing.

 
 There are still some comments below:
 
  ---
   drivers/gpu/drm/i915/i915_drv.h  |  14 ++-
   drivers/gpu/drm/i915/intel_display.c |  58 -
   drivers/gpu/drm/i915/intel_drv.h |  35 --
   drivers/gpu/drm/i915/intel_pm.c  | 229 
  +++
   drivers/gpu/drm/i915/intel_sprite.c  | 119 --
   5 files changed, 347 insertions(+), 108 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/i915_drv.h 
  b/drivers/gpu/drm/i915/i915_drv.h
  index d4f8ae8..5b1404e 100644
  --- a/drivers/gpu/drm/i915/i915_drv.h
  +++ b/drivers/gpu/drm/i915/i915_drv.h
  @@ -405,9 +405,12 @@ struct intel_connector;
   struct intel_crtc_config;
   struct intel_plane_config;
   struct intel_crtc;
  +struct intel_plane;
   struct intel_limit;
   struct dpll;
   struct intel_crtc_wm_config;
  +struct intel_plane_wm_parameters;
  +struct intel_crtc_wm_config;
 
   struct drm_i915_display_funcs {
  bool (*fbc_enabled)(struct drm_device *dev);
  @@ -434,10 +437,13 @@ struct drm_i915_display_funcs {
struct dpll *match_clock,
struct dpll *best_clock);
  void (*update_wm)(struct drm_crtc *crtc);
  -   void (*update_sprite_wm)(struct drm_plane *plane,
  -struct drm_crtc *crtc,
  -uint32_t sprite_width, int pixel_size,
  -bool enable, bool scaled);
  +   int (*update_primary_wm)(struct intel_crtc *crtc,
  +struct intel_crtc_wm_config *config);
  +   int (*update_cursor_wm)(struct intel_crtc *crtc,
  +   struct intel_crtc_wm_config *config);
  +   int (*update_sprite_wm)(struct intel_plane *plane,
  +   struct intel_crtc *crtc,
  +   struct intel_crtc_wm_config *config);
  void (*program_wm_pre)(struct intel_crtc *crtc,
 const struct intel_crtc_wm_config *config);

Re: [Intel-gfx] [PATCH] drm/i915: Disable FBC on Haswell

On Mon, Jun 09, 2014 at 09:12:18PM +0300, Jani Nikula wrote:
 On Fri, 06 Jun 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
  It causes black screen on bootup and is approximately 100x slower than
  running with FBC disabled, so the GPU runs at a high frequency for much
  longer - completely contrary to the power saving claims. It also still
  has mutex deadlocks in multi-head scenarios, which can lead to a
  system/X lockup. These bugs were known before FBC was enabled by default
  on Haswell and still have not been fixed.
 
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79716
  Reported-and-tested-by: Jon Kristensen i...@jonkri.com
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Cc: sta...@vger.kernel.org
  ---
   drivers/gpu/drm/i915/intel_pm.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_pm.c 
  b/drivers/gpu/drm/i915/intel_pm.c
  index e403010540a5..0b8a6010427e 100644
  --- a/drivers/gpu/drm/i915/intel_pm.c
  +++ b/drivers/gpu/drm/i915/intel_pm.c
  @@ -511,8 +511,7 @@ void intel_update_fbc(struct drm_device *dev)
  obj = intel_fb-obj;
  adjusted_mode = intel_crtc-config.adjusted_mode;
   
  -   if (i915.enable_fbc  0 
  -   INTEL_INFO(dev)-gen = 7  !IS_HASWELL(dev)) {
  +   if (i915.enable_fbc  0) {
 
 Not only does this disable FBC by default on Haswell but also on all
 current and future platforms, including Broadwell. Shouldn't you leave
 the INTEL_INFO(dev)-gen = 7 part intact?

The current FBC code is universally broken.

-- 
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] Partial success - Fixing resume from s2ram on S6010


Hi Ville, dear Intel experts,

more on the partial resume from suspend for the S6010. It seems that the 
culprit is really the lack of a proper
initialization of the DVO. The minimum sequence to restore the display 
does not require to modify the 830 registers

directly, but rather needs to setup the DVO.

xrandr --output DVI1 --mode 640x480
# without this, access to the DVO is blocked, thus
# all the following fails. The above initializes the
# PLLs such that the DVO can be accessed.

modprobe i2c-hid
modprobe i2c-algo-bit
modprobe i2c-dev
modprobe i2c-scmi
modprobe i2c-i801
modprobe i2c-ismt
modprobe i2c-gpio
modprobe i2c-piix4
modprobe i2c-isch
modprobe i2c-mux
modprobe i2c-core

#
# Only the following two are required.
i2cset -y 5 0x38 0x34 0x02
i2cset -y 5 0x38 0x35 0x7f

# This restores the old resolution.
xrandr --output DVI1 --mode 1024x768

Thus, it really seems that the culprit is here that the resume operation 
does

not provide access to the DVO correctly.

Greetings,
Thomas

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

[Intel-gfx] [PATCH 1/2] drm/i915: do runtime_get/put during display well power gate/ungate

2014-06-09 Thread sagar . a . kamble

From: Sagar Kamble sagar.a.kam...@intel.com

Display power island is on during boot, we have one count for it
once this power gates, we do a put making sure runtime_suspend is
called

Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM DRIVERS...)
Cc: Jani Nikula jani.nik...@linux.intel.com (supporter:INTEL DRM DRIVERS...)
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
 drivers/gpu/drm/i915/intel_pm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f83d1ff..b333aae 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6017,6 +6017,12 @@ void __vlv_set_power_well(struct drm_i915_private 
*dev_priv,
  state,
  vlv_punit_read(dev_priv, PUNIT_REG_PWRGT_CTRL));
 
+   if (PUNIT_POWER_WELL_DISP2D == power_well_id) {
+   if (enable)
+   intel_runtime_pm_get(dev_priv);
+   else
+   intel_runtime_pm_put(dev_priv);
+   }
 #undef COND
 
 out:
-- 
1.8.5

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

[Intel-gfx] [PATCH 2/2] drm/i915/vlv: Set D3_hot for vlv during runtime_suspend

2014-06-09 Thread sagar . a . kamble

From: Sagar Kamble sagar.a.kam...@intel.com

To do a platform wide S0i3 transition, Gfx is required to go
to D3_hot state. pci_save_state and pci_restore_state needed to avoid ring
hangs across D3_hot transitions.

Cc: Daniel Vetter daniel.vet...@ffwll.ch (supporter:INTEL DRM DRIVERS...)
Cc: Jani Nikula jani.nik...@linux.intel.com (supporter:INTEL DRM DRIVERS...)
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5a08c86..70bb456 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1412,6 +1412,11 @@ static int intel_runtime_suspend(struct device *device)
 * via the suspend path.
 */
intel_opregion_notify_adapter(dev, PCI_D1);
+   if (IS_VALLEYVIEW(dev)) {
+   pci_save_state(pdev);
+   pci_disable_device(pdev);
+   pci_set_power_state(pdev, PCI_D3hot);
+   }
 
DRM_DEBUG_KMS(Device suspended\n);
return 0;
@@ -1428,6 +1433,12 @@ static int intel_runtime_resume(struct device *device)
 
DRM_DEBUG_KMS(Resuming device\n);
 
+   if (IS_VALLEYVIEW(dev)) {
+   pci_set_power_state(pdev, PCI_D0);
+   pci_restore_state(pdev);
+   pci_enable_device(pdev);
+   }
+
intel_opregion_notify_adapter(dev, PCI_D0);
dev_priv-pm.suspended = false;
 
-- 
1.8.5

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

[Intel-gfx] [PATCH 0/2] Enabling D0i3 transition for Valleyview

2014-06-09 Thread sagar . a . kamble

From: Sagar Kamble sagar.a.kam...@intel.com

With these patches runtime_suspend is triggered by updating runtime pm
usage count when display well is power gated and pci state is set to D3 hot
in runtime_suspend and set to D0 in runtime_resume.

Sagar Kamble (2):
  drm/i915: do runtime_get/put during display well power gate/ungate
  drm/i915/vlv: Set D3_hot for vlv during runtime_suspend

 drivers/gpu/drm/i915/i915_drv.c | 11 +++
 drivers/gpu/drm/i915/intel_pm.c |  6 ++
 2 files changed, 17 insertions(+)

-- 
1.8.5

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

Re: [Intel-gfx] [PATCH] drm/i915: Disable FBC on Haswell

2014-06-09 Thread Jani Nikula

On Mon, 09 Jun 2014, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
 On Mon, Jun 09, 2014 at 09:12:18PM +0300, Jani Nikula wrote:
 On Fri, 06 Jun 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
  It causes black screen on bootup and is approximately 100x slower than
  running with FBC disabled, so the GPU runs at a high frequency for much
  longer - completely contrary to the power saving claims. It also still
  has mutex deadlocks in multi-head scenarios, which can lead to a
  system/X lockup. These bugs were known before FBC was enabled by default
  on Haswell and still have not been fixed.
 
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79716
  Reported-and-tested-by: Jon Kristensen i...@jonkri.com
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Cc: sta...@vger.kernel.org
  ---
   drivers/gpu/drm/i915/intel_pm.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_pm.c 
  b/drivers/gpu/drm/i915/intel_pm.c
  index e403010540a5..0b8a6010427e 100644
  --- a/drivers/gpu/drm/i915/intel_pm.c
  +++ b/drivers/gpu/drm/i915/intel_pm.c
  @@ -511,8 +511,7 @@ void intel_update_fbc(struct drm_device *dev)
 obj = intel_fb-obj;
 adjusted_mode = intel_crtc-config.adjusted_mode;
   
  -  if (i915.enable_fbc  0 
  -  INTEL_INFO(dev)-gen = 7  !IS_HASWELL(dev)) {
  +  if (i915.enable_fbc  0) {
 
 Not only does this disable FBC by default on Haswell but also on all
 current and future platforms, including Broadwell. Shouldn't you leave
 the INTEL_INFO(dev)-gen = 7 part intact?

 The current FBC code is universally broken.

Well, then the commit message should reflect that! :p

BR,
Jani.



 -- 
 Ville Syrjälä
 Intel OTC

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

[Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers

2014-06-09 Thread ville . syrjala

From: Ville Syrjälä ville.syrj...@linux.intel.com

In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.

Looks like IEGD does a one time init of these three registers. We don't
have a good one time init place in the ns2501 driver, so let's just
stick them into the .mode_set() hook and see if that helps things along.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
 drivers/gpu/drm/i915/dvo_ns2501.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c 
b/drivers/gpu/drm/i915/dvo_ns2501.c
index 64103cb..4416304 100644
--- a/drivers/gpu/drm/i915/dvo_ns2501.c
+++ b/drivers/gpu/drm/i915/dvo_ns2501.c
@@ -342,6 +342,12 @@ static const struct ns2501_reg regs_1024x768[][86] = {
},
 };
 
+static const struct ns2501_reg regs_init[] = {
+   [0] = { .offset = 0x35, .value = 0xff, },
+   [1] = { .offset = 0x34, .value = 0x00, },
+   [2] = { .offset = 0x08, .value = 0x30, },
+};
+
 struct ns2501_priv {
bool quiet;
const struct ns2501_reg *regs;
@@ -544,6 +550,10 @@ static void ns2501_mode_set(struct intel_dvo_device *dvo,
else
return;
 
+   /* Hopefully doing it every time won't hurt... */
+   for (i = 0; i  ARRAY_SIZE(regs_init); i++)
+   ns2501_writeb(dvo, regs_init[i].offset, regs_init[i].value);
+
ns-regs = regs_1024x768[mode_idx];
 
for (i = 0; i  84; i++)
-- 
1.8.5.5

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

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode for RC6 on bdw

2014-06-09 Thread O'Rourke, Tom

From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, June 03, 2014 12:38 AM
To: O'Rourke, Tom
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Ben Widawsky; Kristen
Carlson Accardi
Subject: Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode for RC6 on
bdw

[TOR:]...snip

  [TOR:] Can we get this patch merged now that RC6 is working on
  drm-intel-
 nightly?

 Needs some review from bdw people. Also some relative residency
 improvement date should be added to the commit message (yes, we're
 allowed to do that now officially).
 -Daniel
 --

 [TOR:] Hello bdw people, please review this patch.

 Is relative performance data now required in the commit message?  A
 week ago this would have been prohibited.

You might need to double-check with your own manager, but we're now again
allowed to officially add it to the commit message. It was kinda always 
required,
just had to be washed down more.
-Daniel

[TOR:] Sorry, I am not allowed to add the performance improvement claims to the 
commit message.  
Tom
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers


Am 09.06.2014 21:46, schrieb ville.syrj...@linux.intel.com:

From: Ville Syrjäläville.syrj...@linux.intel.com

In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.
Thanks, this *almost* works, much better than before. Now I only need to 
switch the console
forth and back to get a display. However, I get a pretty unstable 
display on the console, and
a *sometimes* unstable display on the X display. From the way it looks, 
I would guess that
the synchronization between the display and the PLL is not quite right. 
Which is stunning since

the 830M seems to be configured correctly.

Greetings,
Thomas

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

Re: [Intel-gfx] [PATCH] drm/i915: Init important ns2501 registers