[Intel-gfx] [PATCH] drm/i915: Avoid double mutex lock applying pipe A quirk during sanitize_crtc()
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. 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_release_load_detect_pipe(struct drm_connector *connector, + struct intel_load_detect_pipe *old) +{ + __intel_release_load_detect_pipe(connector, old);
Re: [Intel-gfx] intelgfx-git: Tear-free disabled in the logs
On Sat, Jun 7, 2014 at 4:08 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sat, Jun 07, 2014 at 02:00:46PM +0200, Sedat Dilek wrote: On Sat, Jun 7, 2014 at 1:47 PM, Sedat Dilek sedat.di...@gmail.com wrote: Hi, I am still playing with DRI3... beyond this I saw that TearFree option can be explicitly set (sna: Allow TearFree to be enabled by default via configure), now. I have added TearFree option to my /etc/X11/xorg.conf and still see... $ egrep -i 'sna|uxa|tear' /var/log/Xorg.0.log [ 2501.150] (II) intel(0): SNA compiled from 2.99.911-275-g717e00f [ 2501.151] (**) intel(0): Option AccelMethod sna [ 2501.151] (**) intel(0): Option TearFree true [ 2501.152] (**) intel(0): Tear free disabled [ 2501.154] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend That should be fine. I just broke the log by reporting TearFree before the test whether to enable it. sna: Fix reporting of TearFree [1] fixes the issue for me. - Sedat - P.S.: Next time feel free to give appropriate credits (here: Reported-by), thanks. [1] http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=ecd80a3a997b11307445c50621d4e86e241a5b22 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid double mutex lock applying pipe A quirk during sanitize_crtc()
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
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()
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
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
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
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
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
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?
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
Hi Ville, thanks for the latest patch. As said, the screen did not come back quite correctly. I checked the register values again, and I am sorry to say that I was wrong - register values do differ. Apparently, the code configures now the wrong pipe to generate output to the DVO and thus the DVO does not seem to synchronize correctly anymore. Please find the two register dumps attached. Greetings, Thomas reg.org Description: Binary data DCC: 0x (`7v·ô¿bFx·ä¿ôr·Ø¿dy·) CHDECMISC: 0x (none, ch2 enh disabled, ch1 enh disabled, ch0 enh disabled, flex disabled, ep not present) C0DRB0: 0x (0x) C0DRB1: 0x (0x) C0DRB2: 0x (0x) C0DRB3: 0x (0x) C1DRB0: 0x (0x) C1DRB1: 0x (0x) C1DRB2: 0x (0x) C1DRB3: 0x (0x) C0DRA01: 0x (0x) C0DRA23: 0x (0x) C1DRA01: 0x (0x) C1DRA23: 0x (0x) PGETBL_CTL: 0x3ff60001 VCLK_DIVISOR_VGA0: 0x00021207 (n = 2, m1 = 18, m2 = 7) VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6) VCLK_POST_DIV: 0x888b (vga0 p1 = 13, p2 = 4, vga1 p1 = 10, p2 = 4) DPLL_TEST: 0x (, DPLLA input buffer disabled, DPLLB input buffer disabled) CACHE_MODE_0: 0x001f D_STATE: 0x DSPCLK_GATE_D: 0x0008 (clock gates disabled: OVRUNIT) RENCLK_GATE_D1: 0x RENCLK_GATE_D2: 0x SDVOB: 0x90004084 (enabled, pipe A, stall disabled, detected) SDVOC: 0x (disabled, pipe A, stall disabled, not detected) SDVOUDI: 0x DSPARB: 0x00017e5f DSPFW1: 0x DSPFW2: 0x DSPFW3: 0x ADPA: 0x0c00 (disabled, pipe A, -hsync, -vsync) LVDS: 0x (disabled, pipe A, 18 bit, 1 channel) DVOA: 0x (disabled, pipe A, no stall, -hsync, -vsync) DVOB: 0x90004084 (enabled, pipe A, stall, -hsync, -vsync) DVOC: 0x (disabled, pipe A, no stall, -hsync, -vsync) DVOA_SRCDIM: 0x DVOB_SRCDIM: 0x DVOC_SRCDIM: 0x PP_CONTROL: 0x (power target: off) PP_STATUS: 0x (off, not ready, sequencing idle) PP_ON_DELAYS: 0x PP_OFF_DELAYS: 0x PP_DIVISOR: 0x PFIT_CONTROL: 0x PFIT_PGM_RATIOS: 0x PORT_HOTPLUG_EN: 0x PORT_HOTPLUG_STAT: 0x DSPACNTR: 0xd800 (enabled, pipe A) DSPASTRIDE: 0x2000 (8192 bytes) DSPAPOS: 0x (0, 0) DSPASIZE: 0x02ff03ff (1024, 768) DSPABASE: 0x0200 DSPASURF: 0x DSPATILEOFF: 0x PIPEACONF: 0x8000 (enabled, single-wide) PIPEASRC: 0x03ff02ff (1024, 768) PIPEASTAT: 0x1207 (status: CRC_DONE_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS) PIPEA_GMCH_DATA_M: 0x PIPEA_GMCH_DATA_N: 0x PIPEA_DP_LINK_M: 0x PIPEA_DP_LINK_N: 0x CURSOR_A_BASE: 0x3524c000 CURSOR_A_CONTROL: 0x0427 CURSOR_A_POSITION: 0x00d50133 FPA0: 0x0004150d (n = 4, m1 = 21, m2 = 13) FPA1: 0x0004150d (n = 4, m1 = 21, m2 = 13) DPLL_A: 0xd082 (enabled, dvo, default clock, DAC/serial mode, p1 = 4, p2 = 4) DPLL_A_MD: 0x HTOTAL_A: 0x053f03ff (1024 active, 1344 total) HBLANK_A: 0x053f03ff (1024 start, 1344 end) HSYNC_A: 0x049f0417 (1048 start, 1184 end) VTOTAL_A: 0x032502ff (768 active, 806 total) VBLANK_A: 0x032502ff (768 start, 806 end) VSYNC_A: 0x03080302 (771 start, 777 end) BCLRPAT_A: 0x VSYNCSHIFT_A: 0x DSPBCNTR: 0x (disabled, pipe A) DSPBSTRIDE: 0x (0 bytes) DSPBPOS: 0x (0, 0) DSPBSIZE: 0x (1, 1) DSPBBASE: 0x DSPBSURF: 0x DSPBTILEOFF: 0x PIPEBCONF: 0x (disabled, single-wide) PIPEBSRC: 0x (1, 1) PIPEBSTAT: 0x1004 (status: CRC_DONE_ENABLE SVBLANK_INT_STATUS) PIPEB_GMCH_DATA_M: 0x PIPEB_GMCH_DATA_N: 0x PIPEB_DP_LINK_M: 0x PIPEB_DP_LINK_N: 0x CURSOR_B_BASE: 0x CURSOR_B_CONTROL: 0x CURSOR_B_POSITION: 0x FPB0: 0x00021207 (n = 2, m1 = 18, m2 = 7) FPB1: 0x00021207 (n = 2, m1 = 18,
[Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.7
Hi all, It is time for a new i-g-t release. Thank you all for let everything ready for a smoth release. Here goes a new i-g-t quarterly release with the following changes: - Piles of API documentation for the core i-g-t testing libraries. - Improved igt loggin, now also with igt_vlog (for va_args printf-style logging). - Polish for the igt_debugfs library. - Split out igt_fb library from igt_kms, cleanup of the igt_kms functions. - Android porting patches (Tim Gore, Tvrtko Ursulin). - Piles more tests as usual. - Support for building libcairo based tests on Android. Set ANDROID_HAS_CAIRO=1 in the build enviroment when you have this (Tim Gore). - Timeout support in igt_aux, see igt_set_timeout (Thomas). - Documentation for the testrunner interface like exit codes, subtest enumeration and log output. Should help other people to run the tests in their own framework. - Make swig an optional dependency (Damien). - Helpers for runtime pm tests in igt_aux. Full list of changes: Adrian Negreanu (1): fix out-of-tree builds Ander Conselvan de Oliveira (1): test: Add test for checking if page flip changes tiling Antti Koskipaa (9): kms_cursor_crc: Remove some test cases and change cursor to color kms_cursor_crc: Move cursor enable and disable calls where they belong kms_cursor_crc: Use a function pointer to call test kms_cursor_crc: Separate onscreen and offscreen tests kms_cursor_crc: Add reference software rendering kms_cursor_crc: Add moving cursor test kms_cursor_crc: Add random cursor placement test kms_cursor_crc: Add background picture kms_cursor_crc: Test cursor size change ioctl Ben Widawsky (6): quick_dump: gen8 private PAT intel_gtt: Dump the whole GTT Revert gen8 rendercpy: temporarily disable gem_wait_render_timeout: use igt_assert_cmpint quick_dump: Fix the danvet fallout. quick_dump: Put the cairo cflags with the other cflags. Brad Volkin (8): tests: Add a test for the command parser tests/gem_exec_parse: Add tests for rejected commands tests/gem_exec_parse: Add tests for register whitelist tests/gem_exec_parse: Add tests for bitmask checks tests/gem_exec_parse: Test for batches w/o MI_BATCH_BUFFER_END tests/gem_exec_parse: Test a command crossing a page boundary tests/gem_exec_parse: Test for OACONTROL tracking tests/gen7_forcewake_mt: Don't set the GGTT bit in SRM command Chris Wilson (26): gem_tiled_swapping: Limit to available memory intel-gpu-overlay: Update debugfs path for min/max frequency gem_tiled_swapping: Purge all page/swap caches first gem_tiled_swapping: Test using all available fences Add gem_render_copy_redux Reset errno to 0 after success errno is reset after each syscall overlay: Use new i915_frequency_info in fallback code overlay: Parse /proc/interrupts in lieu of debugfs/i915_gem_interrupt gem_alive: A utility to see if the driver or GPU has hung igt/gem_lut_handle: Fix errno checking igt/gem_render_tiled_blits: Speed up by using the GPU to detile Add gem_bad_reloc gem_bad_reloc: Add subtest for LUT-based execbuffers gem_exec_lut_handle: Do a warm up pass before timing igt/gem_bad_reloc: Restrict negative reloc tests to IVB+ igt/gem_ringfill: Only check for rendercopy when testing render ring igt/gem_bad_reloc: Refine for limited kernel w/a igt/gem_userptr_blits: Fix up last minute API changes Factor in kernel object overhead when checking available memory for tests igt/gem_evict_everything: Move assertion igt/gem_evict_everything: Compute number of surfaces to saturate the aperture lib: Add debug to memory limits checks igt/gem_evict_alignment: Remove obsolete skip on gen8+ igt/gem_evict_alignment: Fix the memory limits checking igt/gem_evict_alignment: Fix the memory limits checking Damien Lespiau (3): build: Define enable_gtk_doc when the m4 macro is missing rendercopy/gen8: Remove a hole in struct gen8_blend_state build: Don't fail if SWIG isn't found Daniel Vetter (126): docs: Exclude debug.xml lib: remove hw context #defines lib/intel_batchbuffer: Remove BATCH_LOCALS lib: api docs for intel_batchbuffer tests/prime_nv_tests: fix copied buffer size lib: switch intel_copy_bo to directly take a size NEWS: post-release blurb and mention api doc work lib/igt_kms: rip out custom verbose loggin support lib: add igt_vlog to print varargs test/kms_pipe_crc_basic: Fix up igt_kms conversion breakage tests/pm_rps: ducttape for igt fork helper cleanup issues tests/pm_rps: simplify load helper setup tests/pm_rps: load harder lib/igt_core: document the caveats of magic code blocks tests/pm_rps: use igt_assert_cmpint tests/pm_rps: wait longer for
[Intel-gfx] Sluggish performance after resume//Re: Bug Report - [Acer Aspire V5-122P] Unable to adjust screen brightness
+Ben Widawsky Daniel Vetter On 06/09/2014 03:38 PM, Lewis Toohey wrote: On 3 June 2014 02:22, Aaron Lu aaron...@intel.com wrote: On 05/30/2014 09:12 PM, Lewis Toohey wrote: Aaron I am in the process of performing this bisection, however, I need a bit of advice. I have got a mix of results following suspend right through from (i) system reboot; (ii) low graphics mode error; (iii) restore but sluggish performance; and (iv) restore but *very* sluggish performance. Is the sluggish performance experienced with a GUI environment? What should qualify as a bad commit? Anything other than a perfect restore? I think ii/iii/iv all qualify as bad, if there is no such problem in previous kernels. And yes, a perfect restore is expected, assume the system is able to do a perfect restore with old kernels. Thanks, Aaron Many thanks Hi Aaron Firstly, yes the sluggish performance I was referring to is experienced in the GUI environment. Jerky graphics and CPU fan appears to max out and stay there. Old kernels (e.g. the Ubuntu default kernel) do not do this and just restore perfectly. I have completed the bisect as requested. Please find the full log below. I am slightly unconvinced, as building the previous commit in the log still seems to have the same problem, however, that commit is a merge and I don't really know what this means. Many thanks Bisect Log: git bisect start # good: [455c6fdbd219161bd09b1165f11699d6d73de11c] Linux 3.14 git bisect good 455c6fdbd219161bd09b1165f11699d6d73de11c # bad: [c9eaa447e77efe77b7fa4c953bd62de8297fd6c5] Linux 3.15-rc1 git bisect bad c9eaa447e77efe77b7fa4c953bd62de8297fd6c5 # good: [cd6362befe4cc7bf589a5236d2a780af2d47bcc9] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next git bisect good cd6362befe4cc7bf589a5236d2a780af2d47bcc9 # good: [d2b150d0647e055d7a71b1c33140280550b27dd6] Merge tag 'sh-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect good d2b150d0647e055d7a71b1c33140280550b27dd6 # good: [5fb6b953bb7aa86a9c8ea760934982cedc45c52b] include/linux/syscalls.h: add sys_renameat2() prototype git bisect good 5fb6b953bb7aa86a9c8ea760934982cedc45c52b # bad: [ffddc5fd19b219f557fd4a81168ce8784a4faced] fs/ncpfs/dir.c: fix indenting in ncp_lookup() git bisect bad ffddc5fd19b219f557fd4a81168ce8784a4faced # bad: [978c6050165bba52eab7ef3581d447eb215def77] Merge branch 'drm-docs' of ssh://people.freedesktop.org/~danvet/drm into drm-next git bisect bad 978c6050165bba52eab7ef3581d447eb215def77 # bad: [262de1453184f65e5ccfe45790f93d41f7339d49] drm/i915: Directly return the vma from bind_to_vm git bisect bad 262de1453184f65e5ccfe45790f93d41f7339d49 # bad: [031994ee8dedfa69d3a7caa43e93f3c282bc38f9] drm/i915: Implement WaIncreaseL3CreditsForVLVB0:vlv git bisect bad 031994ee8dedfa69d3a7caa43e93f3c282bc38f9 # bad: [f72d21eddfa900bfa2674195dcc0203e18d0cc62] drm/i915: Place the Global GTT VM first in the list of VM git bisect bad f72d21eddfa900bfa2674195dcc0203e18d0cc62 # bad: [d6660add648d10e7e35085d8c7d2653e0f9f61b7] drm/i915: Generalize PPGTT init git bisect bad d6660add648d10e7e35085d8c7d2653e0f9f61b7 # bad: [b731d33d05dd5ce6b387cbadb0d9d24cb3732b40] drm/i915: relax context alignment git bisect bad b731d33d05dd5ce6b387cbadb0d9d24cb3732b40 # bad: [a7b910789f77afa40ae0816d22339e9d25723c6e] drm/i915: Add vm to error BO capture git bisect bad a7b910789f77afa40ae0816d22339e9d25723c6e # bad: [6e164c3382314a1f63526fa7a4322a17318d0e32] drm/i915: Allow ggtt lookups to not WARN git bisect bad 6e164c3382314a1f63526fa7a4322a17318d0e32 # bad: [6f425321e02a1b6c5e90b70f8fab7c140fcaeefb] drm/i915: Don't unconditionally try to deref aliasing ppgtt git bisect bad 6f425321e02a1b6c5e90b70f8fab7c140fcaeefb # bad: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO git bisect bad e178f7057b81c87a7ceaae0ca204487b6f7eedcf # first bad commit: [e178f7057b81c87a7ceaae0ca204487b6f7eedcf] drm/i915: Provide PDP updates via MMIO The commit looks like related, I've added the commit author. Ben, Do you have any suggestions? Does the above commit have any chance of causing sluggish performance problem after a resume? Thanks, Aaron ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx