[Intel-gfx] [QA 02/05] Testing report for `drm-intel-testing` (was: Updated -next)

[Sun, Yi]

Summary

We finished a new round of kernel testing. Generally, in this circle, 7 new bug 
is filed, 18 bugs are still opened, 1 bug reopened, 6 bugs are closed.



Test Environment

Kernel: (drm-intel-testing)d138f1fe5e9a8f0eb93bb4eded6195fa6e9ecb0c

Some additional commit info:

Merge: 7d37bea 4518f61

Author: Daniel Vetter daniel.vet...@ffwll.chmailto:daniel.vet...@ffwll.ch

Date:   Fri Feb 1 15:23:25 2013 +0100



Hardware

We covered the platform: Haswell, IvyBridge, SandyBridge, IronLake



Finding Bugs

New Bug:

Bug 5 - [ILK,IVB]kms_flip error: inter-flip ts jitter

Bug 59834 - [ILK]I-G-T/kms_flip subtest: 'wf_vblank-vs-modeset' fail

Bug 6 - [IVB]kms_flip error: inter-vblank ts jitter

Bug 60002 - [PNV]I-G-T/kms_flip subtest：'blocking-absolute-wf_vblank' fail

Bug 59836 - [PNV]igt/kms_flip/absolute-wf_vblank fail

Bug 60307 - [SNB ILK regression] Call trace appears while doing fbset

Bug 60140 - [SNB]igt/kms_flip/flip-vs-modeset-vs-hang causes system hung



Opened Bugs:

Bug  59651-[HSW] DP the screen jitters at 1920x1200

Bug  59339-[ILK] I-G-T/kms_flip subtest: 'flip-vs-panning' fail

Bug  59229-I-G-T/ prime_self_import fail

Bug  58899-[HSW] GPU hung when start X in Ubuntu, with specific kernel com

Bug  58897-[HSW CRW]*ERROR* Unknown unclaimed register

Bug  58799-[HSW B0 desktop] S4 fail to resume

Bug  58791-[ILK] Some modes can't light up on DP display

Bug  58701-[SNB DP]I-G-T/testdisplay  1920x1080i showing not full

Bug  58695-I-G-T/prime_udl fail

Bug  58497-[IVB HSW] I-G-T/testdisplay, there's error in dmesg

Bug  57593-[HSW desktop] screen shift right for some VGA modes

Bug  57441-[HSW]I-G-T/sysfs_l3_parity fail

Bug  54111-[IVB]I-G-T/module_reload fail with *ERROR* “Memory manager not

Bug  51975-[IVB]can't find the HDMI audio device

Bug  47034-[G45] mode set failure with testdisplay, low resolution modes f

Bug  45729-[bisected regression] Incorrect Mode Timing on DP Display, with

Bug  42194-[IVB/SNB] coldplug new monitors for fbcon on lastclose()

Bug  36997-[G45 SDVO] TV can't display -- SDVO xfer fails due to Pending.



Reopened Bugs:

Bug 52424https://bugs.freedesktop.org/show_bug.cgi?id=52424 - [Bisected SNB 
Regression] glxgears causes GPU hung


Closed Bugs:

Bug 59654https://bugs.freedesktop.org/show_bug.cgi?id=59654 - 
[SNB]VGA-1280x800 60 mode can not fill full on DELL-U2410f monitor

Bug 59549https://bugs.freedesktop.org/show_bug.cgi?id=59549 - [HSW]dmesg with 
6 error while booting system

Bug 59750https://bugs.freedesktop.org/show_bug.cgi?id=59750 - [GM45 
regression] system hang while booting up

Bug 59548https://bugs.freedesktop.org/show_bug.cgi?id=59548 - [HSW 
regression]dmesg with 4 error while booting system

Bug 59116https://bugs.freedesktop.org/show_bug.cgi?id=59116 - 
[PNV/ILK/SNB/IVB]I-G-T gem_seqno_wrap fails

Bug 59096https://bugs.freedesktop.org/show_bug.cgi?id=59096 - 
[SNB]I-G-T/gem_render_linear_blits  gem_render_tiled_blits fail

Thanks
--Sun, Yi

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

Re: [Intel-gfx] [PATCH V2 3/3] i915: ignore lid open event when resuming

[Daniel Vetter]

On Tue, Feb 05, 2013 at 03:41:53PM +0800, Zhang Rui wrote:
 oops, forgot to update the changelog and comments.
 refreshed patch attached.
 
 From b584fcebb6d715a317f192c88606b875ee88ce78 Mon Sep 17 00:00:00 2001
 From: Zhang Rui rui.zh...@intel.com
 Date: Thu, 24 Jan 2013 13:27:22 +0800
 Subject: [PATCH V3 3/3] i915: ignore lid open event when resuming
 
 i915 driver needs to do modeset when
 1. system resumes from sleep
 2. lid is opened

Patch applied, thanks. There's been a bit of a merge conflict and one tiny
checkpatch error, both fixed while applying. I plan to push this patch to
drm-next for 3.9.
-Daniel

 
 In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
 thus it is the i915_resume code does the modeset rather than 
 intel_lid_notify().
 
 But in PM_SUSPEND_FREEZE state, this will be broken because
 system is still responsive to the lid events.
 1. When we close the lid in Freeze state, intel_lid_notify() sets 
 modeset_on_lid.
 2. When we reopen the lid, intel_lid_notify() will do a modeset,
before the system is resumed.
 here is the error log,
 
 [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 
 intel_wait_for_pipe_off+0x184/0x190 [i915]()
 [92146.548076] Hardware name: VGN-Z540N
 [92146.548078] pipe_off wait timed out
 [92146.548167] Modules linked in: hid_generic usbhid hid 
 snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev 
 snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 
 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor 
 drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb 
 bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev 
 snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc 
 sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore 
 snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor 
 lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal 
 e1000e
 [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: GW
 3.8.0-rc3-s0i3-v3-test+ #9
 [92146.548175] Call Trace:
 [92146.548189]  [c10378e2] warn_slowpath_common+0x72/0xa0
 [92146.548227]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
 [92146.548263]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
 [92146.548270]  [c10379b3] warn_slowpath_fmt+0x33/0x40
 [92146.548307]  [f86398b4] intel_wait_for_pipe_off+0x184/0x190 [i915]
 [92146.548344]  [f86399c2] intel_disable_pipe+0x102/0x190 [i915]
 [92146.548380]  [f8639ea4] ? intel_disable_plane+0x64/0x80 [i915]
 [92146.548417]  [f8639f7c] i9xx_crtc_disable+0xbc/0x150 [i915]
 [92146.548456]  [f863ebee] intel_crtc_update_dpms+0x5e/0x90 [i915]
 [92146.548493]  [f86437cf] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
 [92146.548535]  [f8645b0b] intel_lid_notify+0x9b/0xc0 [i915]
 [92146.548543]  [c15610d3] notifier_call_chain+0x43/0x60
 [92146.548550]  [c105d1e1] __blocking_notifier_call_chain+0x41/0x80
 [92146.548556]  [c105d23f] blocking_notifier_call_chain+0x1f/0x30
 [92146.548563]  [c131a684] acpi_lid_send_state+0x78/0xa4
 [92146.548569]  [c131aa9e] acpi_button_notify+0x3b/0xf1
 [92146.548577]  [c12df56a] ? acpi_os_execute+0x17/0x19
 [92146.548582]  [c12e591a] ? acpi_ec_sync_query+0xa5/0xbc
 [92146.548589]  [c12e2b82] acpi_device_notify+0x16/0x18
 [92146.548595]  [c12f4904] acpi_ev_notify_dispatch+0x38/0x4f
 [92146.548600]  [c12df0e8] acpi_os_execute_deferred+0x20/0x2b
 [92146.548607]  [c1051208] process_one_work+0x128/0x3f0
 [92146.548613]  [c1564f73] ? common_interrupt+0x33/0x38
 [92146.548618]  [c104f8c0] ? wake_up_worker+0x30/0x30
 [92146.548624]  [c12df0c8] ? acpi_os_wait_events_complete+0x1e/0x1e
 [92146.548629]  [c10524f9] worker_thread+0x119/0x3b0
 [92146.548634]  [c10523e0] ? manage_workers+0x240/0x240
 [92146.548640]  [c1056e84] kthread+0x94/0xa0
 [92146.548647]  [c106] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0
 [92146.548652]  [c15649b7] ret_from_kernel_thread+0x1b/0x28
 [92146.548658]  [c1056df0] ? kthread_create_on_node+0xc0/0xc0
 
 three different modeset flags are introduced in this patch
 MODESET_ON_LID_OPEN: do modeset on next lid open event
 MODESET_DONE:  modeset already done
 MODESET_SUSPENDED:  suspended, only do modeset when system is resumed
 
 In this way,
 1. when lid is closed, MODESET_ON_LID_OPEN is set so that
we'll do modeset on next lid open event.
 2. when lid is opened, MODESET_DONE is set
so that duplicate lid open events will be ignored.
 3. when system suspends, MODESET_SUSPENDED is set.
In this case, we will not do modeset on any lid events.
 
 Plus, locking mechanism is also introduced to avoid racing.
 
 Signed-off-by: Zhang Rui rui.zh...@intel.com
 ---
  drivers/gpu/drm/i915/i915_dma.c   |1 +
  drivers/gpu/drm/i915/i915_drv.c   |   14 +-
  drivers/gpu/drm/i915/i915_drv.h   |   11 +--
  drivers/gpu/drm/i915/intel_lvds.c |   33 

Re: [Intel-gfx] [PATCH V2 3/3] i915: ignore lid open event when resuming

[Rafael J. Wysocki]

On Tuesday, February 05, 2013 11:07:11 AM Daniel Vetter wrote:
 On Tue, Feb 05, 2013 at 03:41:53PM +0800, Zhang Rui wrote:
  oops, forgot to update the changelog and comments.
  refreshed patch attached.
  
  From b584fcebb6d715a317f192c88606b875ee88ce78 Mon Sep 17 00:00:00 2001
  From: Zhang Rui rui.zh...@intel.com
  Date: Thu, 24 Jan 2013 13:27:22 +0800
  Subject: [PATCH V3 3/3] i915: ignore lid open event when resuming
  
  i915 driver needs to do modeset when
  1. system resumes from sleep
  2. lid is opened
 
 Patch applied, thanks. There's been a bit of a merge conflict and one tiny
 checkpatch error, both fixed while applying. I plan to push this patch to
 drm-next for 3.9.

Thanks Daniel!

I will take the other patches from the series, then.

Rafael


  In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
  thus it is the i915_resume code does the modeset rather than 
  intel_lid_notify().
  
  But in PM_SUSPEND_FREEZE state, this will be broken because
  system is still responsive to the lid events.
  1. When we close the lid in Freeze state, intel_lid_notify() sets 
  modeset_on_lid.
  2. When we reopen the lid, intel_lid_notify() will do a modeset,
 before the system is resumed.
  here is the error log,
  
  [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 
  intel_wait_for_pipe_off+0x184/0x190 [i915]()
  [92146.548076] Hardware name: VGN-Z540N
  [92146.548078] pipe_off wait timed out
  [92146.548167] Modules linked in: hid_generic usbhid hid 
  snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep 
  ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy 
  mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor 
  drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm 
  btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev 
  snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc 
  sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore 
  snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf 
  processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci 
  thermal e1000e
  [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: GW
  3.8.0-rc3-s0i3-v3-test+ #9
  [92146.548175] Call Trace:
  [92146.548189]  [c10378e2] warn_slowpath_common+0x72/0xa0
  [92146.548227]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
  [92146.548263]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
  [92146.548270]  [c10379b3] warn_slowpath_fmt+0x33/0x40
  [92146.548307]  [f86398b4] intel_wait_for_pipe_off+0x184/0x190 [i915]
  [92146.548344]  [f86399c2] intel_disable_pipe+0x102/0x190 [i915]
  [92146.548380]  [f8639ea4] ? intel_disable_plane+0x64/0x80 [i915]
  [92146.548417]  [f8639f7c] i9xx_crtc_disable+0xbc/0x150 [i915]
  [92146.548456]  [f863ebee] intel_crtc_update_dpms+0x5e/0x90 [i915]
  [92146.548493]  [f86437cf] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
  [92146.548535]  [f8645b0b] intel_lid_notify+0x9b/0xc0 [i915]
  [92146.548543]  [c15610d3] notifier_call_chain+0x43/0x60
  [92146.548550]  [c105d1e1] __blocking_notifier_call_chain+0x41/0x80
  [92146.548556]  [c105d23f] blocking_notifier_call_chain+0x1f/0x30
  [92146.548563]  [c131a684] acpi_lid_send_state+0x78/0xa4
  [92146.548569]  [c131aa9e] acpi_button_notify+0x3b/0xf1
  [92146.548577]  [c12df56a] ? acpi_os_execute+0x17/0x19
  [92146.548582]  [c12e591a] ? acpi_ec_sync_query+0xa5/0xbc
  [92146.548589]  [c12e2b82] acpi_device_notify+0x16/0x18
  [92146.548595]  [c12f4904] acpi_ev_notify_dispatch+0x38/0x4f
  [92146.548600]  [c12df0e8] acpi_os_execute_deferred+0x20/0x2b
  [92146.548607]  [c1051208] process_one_work+0x128/0x3f0
  [92146.548613]  [c1564f73] ? common_interrupt+0x33/0x38
  [92146.548618]  [c104f8c0] ? wake_up_worker+0x30/0x30
  [92146.548624]  [c12df0c8] ? acpi_os_wait_events_complete+0x1e/0x1e
  [92146.548629]  [c10524f9] worker_thread+0x119/0x3b0
  [92146.548634]  [c10523e0] ? manage_workers+0x240/0x240
  [92146.548640]  [c1056e84] kthread+0x94/0xa0
  [92146.548647]  [c106] ? 
  ftrace_raw_output_sched_stat_runtime+0x70/0xf0
  [92146.548652]  [c15649b7] ret_from_kernel_thread+0x1b/0x28
  [92146.548658]  [c1056df0] ? kthread_create_on_node+0xc0/0xc0
  
  three different modeset flags are introduced in this patch
  MODESET_ON_LID_OPEN: do modeset on next lid open event
  MODESET_DONE:  modeset already done
  MODESET_SUSPENDED:  suspended, only do modeset when system is resumed
  
  In this way,
  1. when lid is closed, MODESET_ON_LID_OPEN is set so that
 we'll do modeset on next lid open event.
  2. when lid is opened, MODESET_DONE is set
 so that duplicate lid open events will be ignored.
  3. when system suspends, MODESET_SUSPENDED is set.
 In this case, we will not do modeset on any lid events.
  
  Plus, locking mechanism is also introduced to avoid racing.
  
  Signed-off-by: Zhang Rui rui.zh...@intel.com
 

[Intel-gfx] [PATCH] tests/gem_ctx_exec: properly test destroy_ctx ioctl

[Mika Kuoppala]

Call context destroy with proper ioctl number and
add test to verify that we can't post batchbuffers
with destroyed context.

Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
 tests/gem_ctx_exec.c |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/gem_ctx_exec.c b/tests/gem_ctx_exec.c
index 423f1ee..b0362cc 100644
--- a/tests/gem_ctx_exec.c
+++ b/tests/gem_ctx_exec.c
@@ -57,7 +57,7 @@ struct local_drm_i915_gem_context_destroy {
 };
 
 #define CONTEXT_CREATE_IOCTL DRM_IOWR(DRM_COMMAND_BASE + 0x2d, struct 
local_drm_i915_gem_context_create)
-#define CONTEXT_DESTROY_IOCTL DRM_IOWR(DRM_COMMAND_BASE + 0x23, struct 
local_drm_i915_gem_context_destroy)
+#define CONTEXT_DESTROY_IOCTL DRM_IOWR(DRM_COMMAND_BASE + 0x2e, struct 
local_drm_i915_gem_context_destroy)
 
 static uint32_t context_create(int fd)
 {
@@ -135,5 +135,7 @@ int main(int argc, char *argv[])
assert(exec(fd, handle, I915_EXEC_RENDER, ctx_id) == 0);
context_destroy(fd, ctx_id);
 
+   assert(exec(fd, handle, I915_EXEC_RENDER, ctx_id)  0);
+
exit(EXIT_SUCCESS);
 }
-- 
1.7.9.5

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

[Intel-gfx] [pull] drm-intel-next for 3.9

[Daniel Vetter]

Hi Dave,

Probably the last feature pull for 3.9, there's some fixes outstanding
thought that I'd like to sneak in. And maybe 3.8 takes a bit longer ...
Anyway, highlights of this pull:
- Kill the horrible IS_DISPLAYREG hack to handle the mmio offset movements
  on vlv, big thanks to Ville.
- Dynamic power well support for Haswell, shaves away a bit when only
  using the eDP port on pipe A (Paulo). Plus unclaimed register fixes
  uncovered by this.
- Clarifications of the gpu hang/reset state transitions, hopefully fixing
  a few spurious -EIO deaths in userspace.
- Haswell ELD fixes.
- Some more (pp)gtt cleanups from Ben.
- A few smaller things all over.

Plus all the stuff from the previous rather small pull request:
- Broadcast RBG improvements and reduced color range fixes from Ville.
- Ben is on a kill legacy gtt code for good spree, first pile of patches
  included.
- No-relocs and bo lut improvements for faster execbuf from Chris.
- Some refactorings from Imre.

QA filed tons of bugs this cycle, all due to us finally enabling all the
really anal timestamp and vblank counter checks in kms_flip, now that the
locking is fixed and EDID reads don't cause stalls any more. In short, our
vblank code seems to be ridiculously racy and broken :( Otoh that's not
really news.

Cheers, Daniel


The following changes since commit b5cc6c0387b2f8d269c1df1e68c97c958dd22fed:

  Merge tag 'drm-intel-next-2012-12-21' of 
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2013-01-17 
20:34:08 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-next-2013-02-01

for you to fetch changes up to 7d37beaaf3dbc6ff16f4d32a4dd6f8c557c6ab50:

  GPU/i915: Fix acpi_bus_get_device() check in 
drivers/gpu/drm/i915/intel_opregion.c (2013-02-01 11:01:50 +0100)


Ben Widawsky (16):
  drm/i915: Kill gtt_end
  drm/i915: Mappable_end can't ever be  end
  drm/i915: Remove gtt_mappable_total
  drm/i915: Create a gtt structure
  drm/i915: Remove use on gma_bus_addr on gen6+
  drm/i915: Remove use of gtt_mappable_entries
  drm/i915: Cut out the infamous ILK w/a from AGP layer
  drm/i915: Remove scratch page from shared
  drm/i915: Needs_dmar, not
  agp/intel: Add gma_bus_addr
  drm/i915: Implement WaVSRefCountFullforceMissDisable
  drm/i915: Error state should print /sys/kernel/debug
  drm/i915: Add probe and remove to the gtt ops
  drm/i915: remove intel_gtt structure
  drm/i915: Reclaim GTT space for failed PPGTT
  drm/i915: Fix CAGF for HSW

Changlong Xie (1):
  drm/i915: gen6_gmch_remove can be static

Chris Wilson (9):
  drm/i915: Add a debug interface to forcibly evict and shrink our object 
caches
  drm/i915: Bail if we attempt to allocate pages for a purged object
  drm/i915: Mark a temporary allocation for copy-from-user as such
  drm/i915: Take the handle idr spinlock once for looking up the exec 
objects
  drm/i915: Move the execbuffer objects list from the stack into the tracker
  drm/i915: Use the reloc.handle as an index into the execbuffer array
  drm/i915: Only insert the mb() before updating the fence parameter
  drm/i915: Only apply the mb() when flushing the GTT domain during a finish
  drm/i915: Only run idle processing from i915_gem_retire_requests_worker

Daniel Vetter (21):
  drm/i915: wake up all pageflip waiters
  drm/i915: Allow userspace to hint that the relocations were known
  drm/i915: move dev_priv-mm out of line
  drm/i915: extract hangcheck/reset/error_state state into substruct
  drm/i915: move wedged to the other gpu error handling stuff
  drm/i915: fix reset handling in the throttle ioctl
  drm/i915: clear up wedged transitions
  drm/i915: create a race-free reset detection
  drm/i915: clarify concurrent hang detect/gpu reset consistency
  drm/i915: fixup sbi_read/write locking
  drm/i915: move modeset checks out of save/restore_modeset_reg
  drm/i915: extract ums suspend/resume into i915_ums.c
  drm/i915: dont save/restore VGA state for kms
  drm/i915: move DP save/restore into i915_ums.c
  drm/i915: vfuncs for gtt_clear_range/insert_entries
  drm/i915: vfuncs for ppgtt
  drm/i915: pte_encode is gen6+
  drm/i915: extract hw ppgtt setup/cleanup code
  drm/i915: kill cargo-culted locking from power well code
  drm/i915: don't run hsw power well code on !hsw
  drm/i915: dynamic Haswell display power well support

Egbert Eich (1):
  drm/i915: Remove pch_rq_mask from struct drm_i915_private.

Imre Deak (3):
  drm/i915: merge get_gtt_alignment/get_unfenced_gtt_alignment()
  drm/i915: merge {i965, sandybridge}_write_fence_reg()
  drm/i915: use gtt_get_size() instead of open coding it

Jani Nikula (3):
  drm/i915: add quirk to invert brightness on eMachines G725
  

[Intel-gfx] [PATCH 4/7] drm/i915: add i915_get_reset_stats_ioctl

[Mika Kuoppala]

This ioctl returns reset stats for specified context.

The struct returned contains context loss counters.
These are:

global_lost:   all resets across all contexts
total_lost:all resets for this context
innocent_lost: contexts lost, guilty was some other context
guilty_lost:   contexts lost, guilty was this context

v2: get rid of state tracking completely and deliver only counts. Idea
from Chris Wilson.

v3: fix commit message

Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
 drivers/gpu/drm/i915/i915_dma.c |1 +
 drivers/gpu/drm/i915/i915_drv.c |   42 +++
 drivers/gpu/drm/i915/i915_drv.h |6 ++
 include/uapi/drm/i915_drm.h |   19 ++
 4 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 82732ee..00b6765 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1882,6 +1882,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_CREATE, 
i915_gem_context_create_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_DESTROY, 
i915_gem_context_destroy_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_REG_READ, i915_reg_read_ioctl, DRM_UNLOCKED),
+   DRM_IOCTL_DEF_DRV(I915_GET_RESET_STATS, i915_get_reset_stats_ioctl, 
DRM_UNLOCKED),
 };
 
 int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index d159d7a..67b023a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -823,6 +823,9 @@ int i915_reset(struct drm_device *dev)
 
i915_gem_reset(dev);
 
+   /* Count unsuccessful ones */
+   dev_priv-reset_count++;
+
ret = -ENODEV;
if (get_seconds() - dev_priv-gpu_error.last_reset  5)
DRM_ERROR(GPU hanging too fast, declaring wedged!\n);
@@ -1228,3 +1231,42 @@ int i915_reg_read_ioctl(struct drm_device *dev,
 
return 0;
 }
+
+int i915_get_reset_stats_ioctl(struct drm_device *dev,
+  void *data, struct drm_file *file)
+{
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   struct intel_ring_buffer *ring;
+   struct drm_i915_file_private *file_priv = file-driver_priv;
+   struct drm_i915_reset_stats *args = data;
+   struct i915_reset_stats *rs = NULL;
+   int ret;
+
+   ret = mutex_lock_interruptible(dev-struct_mutex);
+   if (ret)
+   return ret;
+
+   if (args-ctx_id == 0) {
+   rs = file_priv-reset_stats;
+   ret = 0;
+   goto out;
+   }
+
+   ring = dev_priv-ring[RCS];
+
+   ret = i915_gem_context_get_reset_stats(ring,
+  file,
+  args-ctx_id,
+  rs);
+out:
+   if (rs  ret == 0) {
+   args-global_lost = dev_priv-reset_count;
+   args-total_lost = rs-total;
+   args-innocent_lost = rs-innocent;
+   args-guilty_lost = rs-guilty;
+   }
+
+   mutex_unlock(dev-struct_mutex);
+
+   return ret ? -EINVAL : 0;
+}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 42fcfb6..f43a482 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1040,6 +1040,10 @@ typedef struct drm_i915_private {
/* Old dri1 support infrastructure, beware the dragons ya fools entering
 * here! */
struct i915_dri1_state dri1;
+
+   /* get_reset_stats ioctl */
+   u32 reset_count;
+
 } drm_i915_private_t;
 
 /* Iterate over initialised rings */
@@ -1832,6 +1836,8 @@ extern int intel_enable_rc6(const struct drm_device *dev);
 extern bool i915_semaphore_is_enabled(struct drm_device *dev);
 int i915_reg_read_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+int i915_get_reset_stats_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file);
 
 /* overlay */
 #ifdef CONFIG_DEBUG_FS
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 07d5941..8f4f5e2 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -198,6 +198,7 @@ typedef struct _drm_i915_sarea {
 #define DRM_I915_GEM_SET_CACHING   0x2f
 #define DRM_I915_GEM_GET_CACHING   0x30
 #define DRM_I915_REG_READ  0x31
+#define DRM_I915_GET_RESET_STATS   0x32
 
 #define DRM_IOCTL_I915_INITDRM_IOW( DRM_COMMAND_BASE + 
DRM_I915_INIT, drm_i915_init_t)
 #define DRM_IOCTL_I915_FLUSH   DRM_IO ( DRM_COMMAND_BASE + 
DRM_I915_FLUSH)
@@ -247,6 +248,7 @@ typedef struct _drm_i915_sarea {
 #define DRM_IOCTL_I915_GEM_CONTEXT_CREATE  DRM_IOWR (DRM_COMMAND_BASE + 
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
 #define 

Re: [Intel-gfx] [PATCH] tests/gem_ctx_exec: properly test destroy_ctx ioctl

[Daniel Vetter]

On Tue, Feb 05, 2013 at 12:26:49PM +0200, Mika Kuoppala wrote:
 Call context destroy with proper ioctl number and
 add test to verify that we can't post batchbuffers
 with destroyed context.
 
 Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com

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

Re: [Intel-gfx] [PATCH 00/10] [RFC v2] quick dump

[Damien Lespiau]

On Sun, Feb 03, 2013 at 10:13:10AM -0800, Ben Widawsky wrote:
 - The build kind of sucks on Arch because of Arch's choices regarding
   python libraries. To build this on Arch, you must run something like:
   ./autogen.sh PYTHON_LDFLAGS=-L/usr/lib/python3.3 -lpython3.3m

Don't you have a python3.pc that would allow you to pull the right
flags?

An other detail it that we can't add those hard dependencies to i-g-t,
distributions will hate us (even more). So you'd need to make its
compilation optional.

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

Re: [Intel-gfx] [PATCH V2 3/3] i915: ignore lid open event when resuming

[Zhang Rui]

On Tue, 2013-02-05 at 11:07 +0100, Daniel Vetter wrote:
 On Tue, Feb 05, 2013 at 03:41:53PM +0800, Zhang Rui wrote:
  oops, forgot to update the changelog and comments.
  refreshed patch attached.
  
  From b584fcebb6d715a317f192c88606b875ee88ce78 Mon Sep 17 00:00:00 2001
  From: Zhang Rui rui.zh...@intel.com
  Date: Thu, 24 Jan 2013 13:27:22 +0800
  Subject: [PATCH V3 3/3] i915: ignore lid open event when resuming
  
  i915 driver needs to do modeset when
  1. system resumes from sleep
  2. lid is opened
 
 Patch applied, thanks. There's been a bit of a merge conflict and one tiny
 checkpatch error, both fixed while applying. I plan to push this patch to
 drm-next for 3.9.
 -Daniel
 

great, thanks!

-rui
  
  In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
  thus it is the i915_resume code does the modeset rather than 
  intel_lid_notify().
  
  But in PM_SUSPEND_FREEZE state, this will be broken because
  system is still responsive to the lid events.
  1. When we close the lid in Freeze state, intel_lid_notify() sets 
  modeset_on_lid.
  2. When we reopen the lid, intel_lid_notify() will do a modeset,
 before the system is resumed.
  here is the error log,
  
  [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 
  intel_wait_for_pipe_off+0x184/0x190 [i915]()
  [92146.548076] Hardware name: VGN-Z540N
  [92146.548078] pipe_off wait timed out
  [92146.548167] Modules linked in: hid_generic usbhid hid 
  snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep 
  ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy 
  mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor 
  drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm 
  btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev 
  snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc 
  sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore 
  snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf 
  processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci 
  thermal e1000e
  [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: GW
  3.8.0-rc3-s0i3-v3-test+ #9
  [92146.548175] Call Trace:
  [92146.548189]  [c10378e2] warn_slowpath_common+0x72/0xa0
  [92146.548227]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
  [92146.548263]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
  [92146.548270]  [c10379b3] warn_slowpath_fmt+0x33/0x40
  [92146.548307]  [f86398b4] intel_wait_for_pipe_off+0x184/0x190 [i915]
  [92146.548344]  [f86399c2] intel_disable_pipe+0x102/0x190 [i915]
  [92146.548380]  [f8639ea4] ? intel_disable_plane+0x64/0x80 [i915]
  [92146.548417]  [f8639f7c] i9xx_crtc_disable+0xbc/0x150 [i915]
  [92146.548456]  [f863ebee] intel_crtc_update_dpms+0x5e/0x90 [i915]
  [92146.548493]  [f86437cf] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
  [92146.548535]  [f8645b0b] intel_lid_notify+0x9b/0xc0 [i915]
  [92146.548543]  [c15610d3] notifier_call_chain+0x43/0x60
  [92146.548550]  [c105d1e1] __blocking_notifier_call_chain+0x41/0x80
  [92146.548556]  [c105d23f] blocking_notifier_call_chain+0x1f/0x30
  [92146.548563]  [c131a684] acpi_lid_send_state+0x78/0xa4
  [92146.548569]  [c131aa9e] acpi_button_notify+0x3b/0xf1
  [92146.548577]  [c12df56a] ? acpi_os_execute+0x17/0x19
  [92146.548582]  [c12e591a] ? acpi_ec_sync_query+0xa5/0xbc
  [92146.548589]  [c12e2b82] acpi_device_notify+0x16/0x18
  [92146.548595]  [c12f4904] acpi_ev_notify_dispatch+0x38/0x4f
  [92146.548600]  [c12df0e8] acpi_os_execute_deferred+0x20/0x2b
  [92146.548607]  [c1051208] process_one_work+0x128/0x3f0
  [92146.548613]  [c1564f73] ? common_interrupt+0x33/0x38
  [92146.548618]  [c104f8c0] ? wake_up_worker+0x30/0x30
  [92146.548624]  [c12df0c8] ? acpi_os_wait_events_complete+0x1e/0x1e
  [92146.548629]  [c10524f9] worker_thread+0x119/0x3b0
  [92146.548634]  [c10523e0] ? manage_workers+0x240/0x240
  [92146.548640]  [c1056e84] kthread+0x94/0xa0
  [92146.548647]  [c106] ? 
  ftrace_raw_output_sched_stat_runtime+0x70/0xf0
  [92146.548652]  [c15649b7] ret_from_kernel_thread+0x1b/0x28
  [92146.548658]  [c1056df0] ? kthread_create_on_node+0xc0/0xc0
  
  three different modeset flags are introduced in this patch
  MODESET_ON_LID_OPEN: do modeset on next lid open event
  MODESET_DONE:  modeset already done
  MODESET_SUSPENDED:  suspended, only do modeset when system is resumed
  
  In this way,
  1. when lid is closed, MODESET_ON_LID_OPEN is set so that
 we'll do modeset on next lid open event.
  2. when lid is opened, MODESET_DONE is set
 so that duplicate lid open events will be ignored.
  3. when system suspends, MODESET_SUSPENDED is set.
 In this case, we will not do modeset on any lid events.
  
  Plus, locking mechanism is also introduced to avoid racing.
  
  Signed-off-by: Zhang Rui rui.zh...@intel.com
  ---
   drivers/gpu/drm/i915/i915_dma.c   |1 +

Re: [Intel-gfx] [PATCH V2 3/3] i915: ignore lid open event when resuming

[Zhang Rui]

On Tue, 2013-02-05 at 11:14 +0100, Rafael J. Wysocki wrote:
 On Tuesday, February 05, 2013 11:07:11 AM Daniel Vetter wrote:
  On Tue, Feb 05, 2013 at 03:41:53PM +0800, Zhang Rui wrote:
   oops, forgot to update the changelog and comments.
   refreshed patch attached.
   
   From b584fcebb6d715a317f192c88606b875ee88ce78 Mon Sep 17 00:00:00 2001
   From: Zhang Rui rui.zh...@intel.com
   Date: Thu, 24 Jan 2013 13:27:22 +0800
   Subject: [PATCH V3 3/3] i915: ignore lid open event when resuming
   
   i915 driver needs to do modeset when
   1. system resumes from sleep
   2. lid is opened
  
  Patch applied, thanks. There's been a bit of a merge conflict and one tiny
  checkpatch error, both fixed while applying. I plan to push this patch to
  drm-next for 3.9.
 
 Thanks Daniel!
 
 I will take the other patches from the series, then.
 
great, thank you, Rafael.

-rui
 Rafael
 
 
   In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
   thus it is the i915_resume code does the modeset rather than 
   intel_lid_notify().
   
   But in PM_SUSPEND_FREEZE state, this will be broken because
   system is still responsive to the lid events.
   1. When we close the lid in Freeze state, intel_lid_notify() sets 
   modeset_on_lid.
   2. When we reopen the lid, intel_lid_notify() will do a modeset,
  before the system is resumed.
   here is the error log,
   
   [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 
   intel_wait_for_pipe_off+0x184/0x190 [i915]()
   [92146.548076] Hardware name: VGN-Z540N
   [92146.548078] pipe_off wait timed out
   [92146.548167] Modules linked in: hid_generic usbhid hid 
   snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep 
   ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy 
   mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor 
   drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm 
   btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev 
   snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc 
   sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore 
   snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf 
   processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci 
   sdhci thermal e1000e
   [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: GW
   3.8.0-rc3-s0i3-v3-test+ #9
   [92146.548175] Call Trace:
   [92146.548189]  [c10378e2] warn_slowpath_common+0x72/0xa0
   [92146.548227]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
   [92146.548263]  [f86398b4] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
   [92146.548270]  [c10379b3] warn_slowpath_fmt+0x33/0x40
   [92146.548307]  [f86398b4] intel_wait_for_pipe_off+0x184/0x190 [i915]
   [92146.548344]  [f86399c2] intel_disable_pipe+0x102/0x190 [i915]
   [92146.548380]  [f8639ea4] ? intel_disable_plane+0x64/0x80 [i915]
   [92146.548417]  [f8639f7c] i9xx_crtc_disable+0xbc/0x150 [i915]
   [92146.548456]  [f863ebee] intel_crtc_update_dpms+0x5e/0x90 [i915]
   [92146.548493]  [f86437cf] intel_modeset_setup_hw_state+0x42f/0x8f0 
   [i915]
   [92146.548535]  [f8645b0b] intel_lid_notify+0x9b/0xc0 [i915]
   [92146.548543]  [c15610d3] notifier_call_chain+0x43/0x60
   [92146.548550]  [c105d1e1] __blocking_notifier_call_chain+0x41/0x80
   [92146.548556]  [c105d23f] blocking_notifier_call_chain+0x1f/0x30
   [92146.548563]  [c131a684] acpi_lid_send_state+0x78/0xa4
   [92146.548569]  [c131aa9e] acpi_button_notify+0x3b/0xf1
   [92146.548577]  [c12df56a] ? acpi_os_execute+0x17/0x19
   [92146.548582]  [c12e591a] ? acpi_ec_sync_query+0xa5/0xbc
   [92146.548589]  [c12e2b82] acpi_device_notify+0x16/0x18
   [92146.548595]  [c12f4904] acpi_ev_notify_dispatch+0x38/0x4f
   [92146.548600]  [c12df0e8] acpi_os_execute_deferred+0x20/0x2b
   [92146.548607]  [c1051208] process_one_work+0x128/0x3f0
   [92146.548613]  [c1564f73] ? common_interrupt+0x33/0x38
   [92146.548618]  [c104f8c0] ? wake_up_worker+0x30/0x30
   [92146.548624]  [c12df0c8] ? acpi_os_wait_events_complete+0x1e/0x1e
   [92146.548629]  [c10524f9] worker_thread+0x119/0x3b0
   [92146.548634]  [c10523e0] ? manage_workers+0x240/0x240
   [92146.548640]  [c1056e84] kthread+0x94/0xa0
   [92146.548647]  [c106] ? 
   ftrace_raw_output_sched_stat_runtime+0x70/0xf0
   [92146.548652]  [c15649b7] ret_from_kernel_thread+0x1b/0x28
   [92146.548658]  [c1056df0] ? kthread_create_on_node+0xc0/0xc0
   
   three different modeset flags are introduced in this patch
   MODESET_ON_LID_OPEN: do modeset on next lid open event
   MODESET_DONE:  modeset already done
   MODESET_SUSPENDED:  suspended, only do modeset when system is resumed
   
   In this way,
   1. when lid is closed, MODESET_ON_LID_OPEN is set so that
  we'll do modeset on next lid open event.
   2. when lid is opened, MODESET_DONE is set
  so that duplicate lid open events will be ignored.
   3. when system suspends, 

Re: [Intel-gfx] [PATCH 1/3] PM: make VT switching to the suspend console optional v3

[Jesse Barnes]

On Mon, 04 Feb 2013 21:26:26 +0100
Rafael J. Wysocki r...@sisk.pl wrote:

 On Monday, February 04, 2013 01:37:20 PM Jesse Barnes wrote:
  KMS drivers can potentially restore the display configuration without
  userspace help.  Such drivers can can call a new funciton,
  pm_vt_switch_required(false) if they support this feature.  In that
  case, the PM layer won't VT switch to the suspend console at suspend
  time and then back to the original VT on resume, but rather leave things
  alone for a nicer looking suspend and resume sequence.
  
  v2: make a function so we can handle multiple drivers (Alan)
  v3: use a list to track device requests (Rafael)
  
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 
 Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
 
 for all [1-3/3].

Any chance for an r-b on the PM one at least?  Then Daniel could
probably push this through drm-intel-next.

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

Re: [Intel-gfx] [PATCH 04/22] drm/i915: implement WaGTEnableMiFlush on VLV

[Ville Syrjälä]

On Sat, Feb 02, 2013 at 01:56:08PM +0100, Jesse Barnes wrote:
 We don't generally use MI_FLUSH these days, but this bit may affect
 other flushing logic, so set it to be safe.
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
 b/drivers/gpu/drm/i915/intel_ringbuffer.c
 index 2bd074a..5a9e26a 100644
 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
 +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
 @@ -511,6 +511,9 @@ static int init_render_ring(struct intel_ring_buffer 
 *ring)
   I915_WRITE(GFX_MODE_GEN7,
  
 _MASKED_BIT_DISABLE(GFX_TLB_INVALIDATE_ALWAYS) |
  _MASKED_BIT_ENABLE(GFX_REPLAY_MODE));
 + if (IS_VALLEYVIEW(dev))
 + I915_WRITE(MI_MODE, I915_READ(MI_MODE) |
 +_MASKED_BIT_ENABLE(MI_FLUSH_ENABLE));

Include a comment with the WA name?

Also this WA seems to be present since SNB. So should the check be for
'gen=6' instead of VLV? Hmm. It seems that used to be the case actually
and then the WA was removed in commit:

 commit 8d79c3490aecfe6e51f0ba6f9780746fb1434954
 Author: Eric Anholt e...@anholt.net
 Date:   Thu Jan 19 10:50:05 2012 -0800

drm/i915: Remove the MI_FLUSH_ENABLE setting.

We have always been using the wrong bit -- it's bit 12.  However, the
bit also doesn't do anything -- hardware has always accepted the
MI_FLUSH command even when it was specced not to.

Given that there is only one MI_FLUSH emitted in all of the driver
stack on gen6+ (in i965_video.c of the 2d driver, and it should be
using other code to do its flush instead), just remove the MI_FLUSH
enable instead of trying to fix it.

Signed-off-by: Eric Anholt e...@anholt.net
Reviewed-by: Kenneth Graunke kenn...@whitecape.org
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch

Looks like the wrong bit part was fixed at some point.

This patch needs to be refreshed anyway since the code was shuffled
around a bit.

   }
  
   if (INTEL_INFO(dev)-gen = 5) {
 -- 
 1.7.9.5
 
 ___
 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] [PATCH 05/22] drm/i915: enable force wake, disable LLC on VLV

[Ville Syrjälä]

On Sat, Feb 02, 2013 at 01:56:09PM +0100, Jesse Barnes wrote:
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/i915_drv.c |4 
  1 file changed, 4 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
 index 13b9b4f..b35b479 100644
 --- a/drivers/gpu/drm/i915/i915_drv.c
 +++ b/drivers/gpu/drm/i915/i915_drv.c
 @@ -276,6 +276,8 @@ static const struct intel_device_info 
 intel_valleyview_m_info = {
   .has_bsd_ring = 1,
   .has_blt_ring = 1,
   .is_valleyview = 1,
 + .has_force_wake = 1,
 + .has_llc = 0,
  };
  
  static const struct intel_device_info intel_valleyview_d_info = {
 @@ -285,6 +287,8 @@ static const struct intel_device_info 
 intel_valleyview_d_info = {
   .has_bsd_ring = 1,
   .has_blt_ring = 1,
   .is_valleyview = 1,
 + .has_force_wake = 1,
 + .has_llc = 0,
  };

It looks like we never set these flags to 0 explicitly. It's using
named initializers so the rest gets initialized to 0 anyway.

  
  static const struct intel_device_info intel_haswell_d_info = {
 -- 
 1.7.9.5
 
 ___
 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] [PATCH 08/10] quick_dump: SWIG chipset interface

[Matt Turner]

On Sat, Feb 2, 2013 at 4:08 PM, Ben Widawsky b...@bwidawsk.net wrote:
 This isn't strictly necessary it would have been easy enough to simply
 convert intel_chipset.h but this should be nice prep work for directly
 doing MMIO. It also serves as a nice review point.

 It's demonstrated with an autodetect function in the script. That
 autodetect has a hardcoded path that shouldn't be there, but it will go
 away in the next patch when we can properly link in libpciaccess.

 Thanks to Matt for helping whip the automake stuff into shape.

 Cc: Matt Turner matts...@gmail.com
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---

Patches 7  8 are Reviewed-by: Matt Turner matts...@gmail.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 20/22] drm/i915: add Punit read/write routines for VLV

[Jani Nikula]

On Sat, 02 Feb 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
 Slightly different than other platforms.

I'll do more review later, just pointing out an obvious bug below.

BR,
Jani.



 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/i915_drv.h |2 ++
  drivers/gpu/drm/i915/i915_reg.h |   22 
  drivers/gpu/drm/i915/intel_pm.c |   74 
 +++
  3 files changed, 98 insertions(+)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 34f01a9..60eee7d 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1749,6 +1749,8 @@ int __gen6_gt_wait_for_fifo(struct drm_i915_private 
 *dev_priv);
  
  int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u8 mbox, u32 
 *val);
  int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u8 mbox, u32 
 val);
 +int valleyview_punit_read(struct drm_i915_private *dev_priv, u8 addr, u32 
 *val);
 +int valleyview_punit_write(struct drm_i915_private *dev_priv, u8 addr, u32 
 val);
  
  #define __i915_read(x, y) \
   u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg, bool 
 trace);
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 7e13f34..7325b7a 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -4335,6 +4335,28 @@
  #define GEN6_PCODE_DATA  0x138128
  #define   GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
  
 +#define VLV_IOSF_DOORBELL_REQ0x182100
 +#define   IOSF_DEVFN_SHIFT   24
 +#define   IOSF_OPCODE_SHIFT  16
 +#define   IOSF_PORT_SHIFT8
 +#define   IOSF_BYTE_ENABLES_SHIFT4
 +#define   IOSF_BAR_SHIFT 1
 +#define   IOSF_SB_BUSY   (10)
 +#define   IOSF_PORT_PUNIT0x4
 +#define VLV_IOSF_DATA0x182104
 +#define VLV_IOSF_ADDR0x182108
 +
 +#define PUNIT_REG_GPU_LFM0xd3
 +#define PUNIT_REG_GPU_FREQ_REQ   0xd4
 +#define PUNIT_REG_GPU_FREQ_STS   0xd8
 +#define PUNIT_REG_MEDIA_TURBO_FREQ_REQ   0xdc
 +
 +#define PUNIT_OPCODE_REG_READ6
 +#define PUNIT_OPCODE_REG_WRITE   7
 +
 +#define PUNIT_FUSE_BUS2  0xf6 /* bits 47:40 */
 +#define PUNIT_FUSE_BUS1  0xf5 /* bits 55:48 */
 +
  #define GEN6_GT_CORE_STATUS  0x138060
  #define   GEN6_CORE_CPD_STATE_MASK   (74)
  #define   GEN6_RCn_MASK  7
 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index 7d812ba..bb97309 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -4356,3 +4356,77 @@ int sandybridge_pcode_write(struct drm_i915_private 
 *dev_priv, u8 mbox, u32 val)
  
   return 0;
  }
 +
 +int valleyview_punit_read(struct drm_i915_private *dev_priv, u8 addr, u32 
 *val)
 +{
 + u32 cmd, devfn, opcode, port, be, bar;
 +
 + bar = 0;
 + be = 0xf;
 + port = IOSF_PORT_PUNIT;
 + opcode = PUNIT_OPCODE_REG_READ;
 + devfn = 16;
 +
 + cmd = (devfn  IOSF_DEVFN_SHIFT) | (opcode  IOSF_OPCODE_SHIFT) |
 + (port  IOSF_PORT_SHIFT) | (be | IOSF_BYTE_ENABLES_SHIFT) |

Should be (be  IOSF_BYTE_ENABLES_SHIFT).

 + (bar  IOSF_BAR_SHIFT);
 +
 + WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
 +
 + if (I915_READ(VLV_IOSF_DOORBELL_REQ)  IOSF_SB_BUSY) {
 + DRM_DEBUG_DRIVER(warning: pcode (read) mailbox access 
 failed\n);
 + return -EAGAIN;
 + }
 +
 + I915_WRITE(VLV_IOSF_ADDR, addr);
 + I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd);
 +
 + if (wait_for((I915_READ(VLV_IOSF_DOORBELL_REQ)  IOSF_SB_BUSY) == 0,
 +  500)) {
 + DRM_ERROR(timeout waiting for pcode read (%d) to finish\n,
 +   addr);
 + return -ETIMEDOUT;
 + }
 +
 + *val = I915_READ(VLV_IOSF_DATA);
 + I915_WRITE(VLV_IOSF_DATA, 0);
 +
 + return 0;
 +}
 +
 +int valleyview_punit_write(struct drm_i915_private *dev_priv, u8 addr, u32 
 val)
 +{
 + u32 cmd, devfn, opcode, port, be, bar;
 +
 + bar = 0;
 + be = 0xf;
 + port = IOSF_PORT_PUNIT;
 + opcode = PUNIT_OPCODE_REG_WRITE;
 + devfn = 16;
 +
 + cmd = (devfn  IOSF_DEVFN_SHIFT) | (opcode  IOSF_OPCODE_SHIFT) |
 + (port  IOSF_PORT_SHIFT) | (be | IOSF_BYTE_ENABLES_SHIFT) |

Ditto.

The obvious copy-pasting makes me note the read/write functions are
roughly the same... would it make sense to have a static common routine
behind the interface functions? Just add opcode parameter, and do *val =
I915_READ(VLV_IOSF_DATA) and I915_WRITE(VLV_IOSF_DATA, *val) depending
on that.

 + (bar  IOSF_BAR_SHIFT);
 +

Re: [Intel-gfx] [PATCH 06/22] drm/i915: add power context allocation and setup on VLV

[Ville Syrjälä]

On Sat, Feb 02, 2013 at 01:56:10PM +0100, Jesse Barnes wrote:
 The Gunit has a separate reg for this, so allocate some stolen space for
 the power context and initialize the reg.

AFAIK the BIOS is responsible for setting up the PCBR register. The
register can also be locked preventing further updates, so if the BIOS
actually has done what it's supposed to, this code will fail.

So should we just instead read out the PCBR and remove the range from
the stolen mem pool?

 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/i915_drv.h|2 ++
  drivers/gpu/drm/i915/i915_gem_stolen.c |   41 
 
  drivers/gpu/drm/i915/i915_reg.h|1 +
  3 files changed, 44 insertions(+)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index f4ae73d..34f01a9 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -928,6 +928,8 @@ typedef struct drm_i915_private {
   struct drm_mm_node *compressed_fb;
   struct drm_mm_node *compressed_llb;
  
 + struct drm_mm_node *vlv_pctx;
 +
   unsigned long last_gpu_reset;
  
   /* list of fbdev register on this device */
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index f21ae17..ac11a41 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -171,11 +171,49 @@ void i915_gem_stolen_cleanup_compression(struct 
 drm_device *dev)
   dev_priv-cfb_size = 0;
  }
  
 +static void i915_setup_pctx(struct drm_device *dev)
 +{
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + struct drm_mm_node *pctx;
 + unsigned long pctx_paddr;
 + int pctx_size = 24*1024;
 +
 + pctx = drm_mm_search_free(dev_priv-mm.stolen, pctx_size, 4096, 0);
 + if (pctx)
 + pctx = drm_mm_get_block(pctx, pctx_size, 4096);
 + if (!pctx)
 + goto err;
 +
 + pctx_paddr = dev_priv-mm.stolen_base + pctx-start;
 + if (!pctx_paddr)
 + goto err_free_pctx;
 +
 + dev_priv-vlv_pctx = pctx;
 + I915_WRITE(VLV_PCBR, pctx_paddr);
 +
 + return;
 +
 +err_free_pctx:
 + drm_mm_put_block(pctx);
 +err:
 + DRM_DEBUG(not enough stolen space for PCTX, disabling\n);
 +}
 +
 +static void i915_cleanup_pctx(struct drm_device *dev)
 +{
 + struct drm_i915_private *dev_priv = dev-dev_private;
 +
 + I915_WRITE(VLV_PCBR, 0);
 + drm_mm_put_block(dev_priv-vlv_pctx);
 +}
 +
  void i915_gem_cleanup_stolen(struct drm_device *dev)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
  
   i915_gem_stolen_cleanup_compression(dev);
 + if (IS_VALLEYVIEW(dev)  i915_powersave)
 + i915_cleanup_pctx(dev);
   drm_mm_takedown(dev_priv-mm.stolen);
  }
  
 @@ -193,6 +231,9 @@ int i915_gem_init_stolen(struct drm_device *dev)
   /* Basic memrange allocator for stolen space */
   drm_mm_init(dev_priv-mm.stolen, 0, dev_priv-mm.gtt-stolen_size);
  
 + if (IS_VALLEYVIEW(dev)  i915_powersave)
 + i915_setup_pctx(dev);
 +
   return 0;
  }
  
 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 286bab3..c785750 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -561,6 +561,7 @@
  #define ISR  0x020ac
  #define VLV_GUNIT_CLOCK_GATE 0x182060
  #define   GCFG_DIS   (18)
 +#define VLV_PCBR 0x182120
  #define VLV_IIR_RW   0x182084
  #define VLV_IER  0x1820a0
  #define VLV_IIR  0x1820a4
 -- 
 1.7.9.5
 
 ___
 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] [PATCH 06/22] drm/i915: add power context allocation and setup on VLV

[Jesse Barnes]

On Tue, 5 Feb 2013 20:01:15 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:

 On Sat, Feb 02, 2013 at 01:56:10PM +0100, Jesse Barnes wrote:
  The Gunit has a separate reg for this, so allocate some stolen space for
  the power context and initialize the reg.
 
 AFAIK the BIOS is responsible for setting up the PCBR register. The
 register can also be locked preventing further updates, so if the BIOS
 actually has done what it's supposed to, this code will fail.
 
 So should we just instead read out the PCBR and remove the range from
 the stolen mem pool?

At the very least.  I'll have to check with the BIOS folks; I'm pretty
sure on some machines we'll need to do this ourselves.

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

[Intel-gfx] [PATCH] Build: Add --disable-tests configure flag to avoid tests build - v2

[Rodrigo Vivi]

Tests are still being built by default. However this request
came from OSVs in order to allow them to include i-g-t in their
distributions by default avoiding adding more and more dependencies
since we are improving and adding more and more tests.

v2: wait for Ben's spacin fixes and adjusted for new space rules.

Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com

Conflicts:
configure.ac
---
 Makefile.am  |  6 +-
 configure.ac | 11 ++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 5ea0fd8..0dd615b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -21,12 +21,16 @@
 
 ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS}
 
-SUBDIRS = lib man tools scripts tests benchmarks demos
+SUBDIRS = lib man tools scripts benchmarks demos
 
 if BUILD_SHADER_DEBUGGER
 SUBDIRS += debugger
 endif
 
+if BUILD_TESTS
+SUBDIRS += tests
+endif
+
 test:
${MAKE} -C tests test
 
diff --git a/configure.ac b/configure.ac
index 1c56fa4..e66876c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -122,6 +122,16 @@ AM_CONDITIONAL(BUILD_SHADER_DEBUGGER, [test 
x$BUILD_SHADER_DEBUGGER != xno])
 XORG_TESTSET_CFLAG([THREAD_CFLAGS], [-pthread], [-mt])
 AC_SUBST([THREAD_CFLAGS])
 
+AC_ARG_ENABLE(tests,
+ AS_HELP_STRING([--disable-tests],
+ [Disable tests build (default: enabled)]),
+ [BUILD_TESTS=$enableval], [BUILD_TESTS=yes])
+if test x$BUILD_TESTS = xyes; then
+   AC_DEFINE(BUILD_TESTS, 1, [Build tests])
+   AC_CONFIG_FILES([tests/Makefile])
+fi
+AM_CONDITIONAL(BUILD_TESTS, [test x$BUILD_TESTS = xyes])
+
 AC_CONFIG_FILES([
 Makefile
 benchmarks/Makefile
@@ -129,7 +139,6 @@ AC_CONFIG_FILES([
 lib/Makefile
 man/Makefile
 scripts/Makefile
-tests/Makefile
 tools/Makefile
 debugger/Makefile
 debugger/system_routine/Makefile
-- 
1.7.11.7

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

Re: [Intel-gfx] [PATCH 1/3] PM: make VT switching to the suspend console optional v3

[Rafael J. Wysocki]

On Monday, February 04, 2013 01:37:20 PM Jesse Barnes wrote:
 KMS drivers can potentially restore the display configuration without
 userspace help.  Such drivers can can call a new funciton,
 pm_vt_switch_required(false) if they support this feature.  In that
 case, the PM layer won't VT switch to the suspend console at suspend
 time and then back to the original VT on resume, but rather leave things
 alone for a nicer looking suspend and resume sequence.
 
 v2: make a function so we can handle multiple drivers (Alan)
 v3: use a list to track device requests (Rafael)
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org

Reviewed-by: Rafael J. Wysocki rafael.j.wyso...@intel.com

 ---
  include/linux/pm.h |4 ++
  kernel/power/console.c |  115 
 
  2 files changed, 119 insertions(+)
 
 diff --git a/include/linux/pm.h b/include/linux/pm.h
 index 03d7bb1..98310eb 100644
 --- a/include/linux/pm.h
 +++ b/include/linux/pm.h
 @@ -35,6 +35,10 @@ extern void (*pm_idle)(void);
  extern void (*pm_power_off)(void);
  extern void (*pm_power_off_prepare)(void);
  
 +struct device; /* we have a circular dep with device.h */
 +extern void pm_vt_switch_required(struct device *dev, bool required);
 +extern void pm_vt_switch_unregister(struct device *dev);
 +
  /*
   * Device power management
   */
 diff --git a/kernel/power/console.c b/kernel/power/console.c
 index b1dc456..4871ca9 100644
 --- a/kernel/power/console.c
 +++ b/kernel/power/console.c
 @@ -4,6 +4,7 @@
   * Originally from swsusp.
   */
  
 +#include linux/console.h
  #include linux/vt_kern.h
  #include linux/kbd_kern.h
  #include linux/vt.h
 @@ -14,8 +15,119 @@
  
  static int orig_fgconsole, orig_kmsg;
  
 +DEFINE_MUTEX(vt_switch_mutex);
 +
 +struct pm_vt_switch {
 + struct list_head head;
 + struct device *dev;
 + bool required;
 +};
 +
 +LIST_HEAD(pm_vt_switch_list);
 +
 +
 +/**
 + * pm_vt_switch_required - indicate VT switch at suspend requirements
 + * @dev: device
 + * @required: if true, caller needs VT switch at suspend/resume time
 + *
 + * The different console drivers may or may not require VT switches across
 + * suspend/resume, depending on how they handle restoring video state and
 + * what may be running.
 + *
 + * Drivers can indicate support for switchless suspend/resume, which can
 + * save time and flicker, by using this routine and passing 'false' as
 + * the argument.  If any loaded driver needs VT switching, or the
 + * no_console_suspend argument has been passed on the command line, VT
 + * switches will occur.
 + */
 +void pm_vt_switch_required(struct device *dev, bool required)
 +{
 + struct pm_vt_switch *entry, *tmp;
 +
 + mutex_lock(vt_switch_mutex);
 + list_for_each_entry(tmp, pm_vt_switch_list, head) {
 + if (tmp-dev == dev) {
 + /* already registered, update requirement */
 + tmp-required = required;
 + goto out;
 + }
 + }
 +
 + entry = kmalloc(sizeof(*entry), GFP_KERNEL);
 + if (!entry)
 + goto out;
 +
 + entry-required = required;
 + entry-dev = dev;
 +
 + list_add(entry-head, pm_vt_switch_list);
 +out:
 + mutex_unlock(vt_switch_mutex);
 +}
 +EXPORT_SYMBOL(pm_vt_switch_required);
 +
 +/**
 + * pm_vt_switch_unregister - stop tracking a device's VT switching needs
 + * @dev: device
 + *
 + * Remove @dev from the vt switch list.
 + */
 +void pm_vt_switch_unregister(struct device *dev)
 +{
 + struct pm_vt_switch *tmp;
 +
 + mutex_lock(vt_switch_mutex);
 + list_for_each_entry(tmp, pm_vt_switch_list, head) {
 + if (tmp-dev == dev) {
 + list_del(tmp-head);
 + break;
 + }
 + }
 + mutex_unlock(vt_switch_mutex);
 +}
 +
 +/*
 + * There are three cases when a VT switch on suspend/resume are required:
 + *   1) no driver has indicated a requirement one way or another, so preserve
 + *  the old behavior
 + *   2) console suspend is disabled, we want to see debug messages across
 + *  suspend/resume
 + *   3) any registered driver indicates it needs a VT switch
 + *
 + * If none of these conditions is present, meaning we have at least one 
 driver
 + * that doesn't need the switch, and none that do, we can avoid it to make
 + * resume look a little prettier (and suspend too, but that's usually hidden,
 + * e.g. when closing the lid on a laptop).
 + */
 +static bool pm_vt_switch(void)
 +{
 + struct pm_vt_switch *entry;
 + bool ret = true;
 +
 + mutex_lock(vt_switch_mutex);
 + if (list_empty(pm_vt_switch_list))
 + goto out;
 +
 + if (!console_suspend_enabled)
 + goto out;
 +
 + list_for_each_entry(entry, pm_vt_switch_list, head) {
 + if (entry-required)
 + goto out;
 + }
 +
 + ret = false;
 +out:
 + mutex_unlock(vt_switch_mutex);
 + return ret;
 +}
 +
  int 

Re: [Intel-gfx] [PATCH 1/3] PM: make VT switching to the suspend console optional v3

[Rafael J. Wysocki]

On Tuesday, February 05, 2013 01:55:44 PM Jesse Barnes wrote:
 On Mon, 04 Feb 2013 21:26:26 +0100
 Rafael J. Wysocki r...@sisk.pl wrote:
 
  On Monday, February 04, 2013 01:37:20 PM Jesse Barnes wrote:
   KMS drivers can potentially restore the display configuration without
   userspace help.  Such drivers can can call a new funciton,
   pm_vt_switch_required(false) if they support this feature.  In that
   case, the PM layer won't VT switch to the suspend console at suspend
   time and then back to the original VT on resume, but rather leave things
   alone for a nicer looking suspend and resume sequence.
   
   v2: make a function so we can handle multiple drivers (Alan)
   v3: use a list to track device requests (Rafael)
   
   Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  
  Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
  
  for all [1-3/3].
 
 Any chance for an r-b on the PM one at least?  Then Daniel could
 probably push this through drm-intel-next.

Done.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, 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] Build: Add --disable-tests configure flag to avoid tests build - v2

[Paul Menzel]

Dear Rodrigo,


Am Dienstag, den 05.02.2013, 16:17 -0200 schrieb Rodrigo Vivi:
 Tests are still being built by default. However this request
 came from OSVs in order to allow them to include i-g-t in their

Please do not use abbreviations which do not even show up in the top ten
hits when searching for them in the Google search engine.

 distributions by default avoiding adding more and more dependencies
 since we are improving and adding more and more tests.
 
 v2: wait for Ben's spacin fixes and adjusted for new space rules.

For the subject line from `git help format-pactch`:

$ git format-patch --subject-prefix=PATCH v2

 Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
 
 Conflicts:
   configure.ac

As it is just locale for you, you can remove this, right?

 ---
  Makefile.am  |  6 +-
  configure.ac | 11 ++-
  2 files changed, 15 insertions(+), 2 deletions(-)

[…]

With the changes above,

Acked-by: Paul Menzel paulepan...@users.sourceforge.net


Thanks,

Paul


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] [PATCH 2/2] configure.ac: Do not include `x11-xcb`, `xcb-dri2` and `xcb-aux` in `XVMCLIB`

[Paul Menzel]

Am Montag, den 04.02.2013, 22:28 +0100 schrieb Julien Cristau:
 On Sun, Feb  3, 2013 at 13:29:04 +0100, Paul Menzel wrote:
 
  I was surprised too that no error was generated. Do you have any idea
  why compilations succeeds?

 Fails to build here with
 ../../../src/xvmc/intel_xvmc.c:29:25: fatal error: xcb/xcb_aux.h: No such 
 file or directory

I wonder where our build environments differ.

 Also, shared libraries, as opposed to executable binaries, are allowed
 to have undefined symbols.

Sorry, as I cannot range in this comment, could you please elaborate.

 Try this:
 
 -libIntelXvMC_la_LDFLAGS = -version-number 1:0:0
 +libIntelXvMC_la_LDFLAGS = -version-number 1:0:0 -Wl,-z,defs

Thanks. With these flags/switches the build indeed fails. (Reading `man
ld` was also helpful to me.)

[…]
CC intel_batchbuffer.lo
CCLD   libIntelXvMC.la
.libs/intel_xvmc.o: In function `XvMCCreateContext':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:282:
 undefined reference to `XFree'
.libs/intel_xvmc.o: In function `dri2_connect':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:131:
 undefined reference to `XGetXCBConnection'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:137:
 undefined reference to `xcb_aux_get_screen'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:139:
 undefined reference to `xcb_dri2_id'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:139:
 undefined reference to `xcb_get_extension_dat

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:147:
 undefined reference to `xcb_dri2_query_versio

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:148:
 undefined reference to `xcb_dri2_connect'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:150:
 undefined reference to `xcb_dri2_query_versio

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:152:
 undefined reference to `xcb_dri2_connect_repl

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:160:
 undefined reference to `xcb_dri2_connect_devi

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:166:
 undefined reference to `xcb_dri2_connect_devi
.libs/intel_xvmc.o: In function `XvMCCreateContext':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:301:
 undefined reference to `XFree'
.libs/intel_xvmc.o: In function `dri2_connect':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:181:
 undefined reference to `xcb_dri2_authenticate

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:182:
 undefined reference to `xcb_dri2_authenticate
.libs/intel_xvmc.o: In function `XvMCCreateContext':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:323:
 undefined reference to `XFree'
.libs/intel_xvmc.o: In function `XvMCCreateSurface':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:407:
 undefined reference to `XFree'
.libs/intel_xvmc.o: In function `XvMCDestroySurface':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:458:
 undefined reference to `XFree'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:460:
 undefined reference to `XFreeGC'
.libs/intel_xvmc.o: In function `XvMCPutSurface':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:651:
 undefined reference to `XFreeGC'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:652:
 undefined reference to `XCreateGC'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/intel_xvmc.c:648:
 undefined reference to `XCreateGC'
.libs/i915_xvmc.o: In function `i915_xvmc_mc_create_context':

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/i915_xvmc.c:915: 
undefined reference to `XFree'

/src/xserver-xorg-video-intel/build/src/xvmc/../../../src/xvmc/i915_xvmc.c:933: 
undefined reference to `XFree'
collect2: error: ld returned 1 exit status
make[5]: *** [libIntelXvMC.la] Fehler 1
[…]


Thanks,

Paul


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] [PATCH V2 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE

[Zhang Rui]

On Mon, 2013-02-04 at 15:10 +0800, Zhang Rui wrote:
 PM_SUSPEND_FREEZE state is a general state that
 does not need any platform specific support, it equals
 frozen processes + suspended devices + idle processors.
 
 Compared with PM_SUSPEND_MEMORY,
 PM_SUSPEND_FREEZE saves less power
 because the system is still in a running state.
 PM_SUSPEND_FREEZE has less resume latency because it does not
 touch BIOS, and the processors are in idle state.
 
 Compared with RTPM/idle,
 PM_SUSPEND_FREEZE saves more power as
 1. the processor has longer sleep time because processes are frozen.
The deeper c-state the processor supports, more power saving we can get.
 2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get
more power saving from the devices that does not have good RTPM support.
 
 This state is useful for
 1) platforms that do not have STR, or have a broken STR.
 2) platforms that have an extremely low power idle state,
which can be used to replace STR.
 
 The following describes how PM_SUSPEND_FREEZE state works.
 1. echo freeze  /sys/power/state
 2. the processes are frozen.
 3. all the devices are suspended.
 4. all the processors are blocked by a wait queue
 5. all the processors idles and enters (Deep) c-state.
 6. an interrupt fires.
 7. a processor is woken up and handles the irq.
 8. if it is a general event,
a) the irq handler runs and quites.
b) goto step 4.
 9. if it is a real wake event, say, power button pressing, keyboard touch, 
 mouse moving,
a) the irq handler runs and activate the wakeup source
b) wakeup_source_activate() notifies the wait queue.
c) system starts resuming from PM_SUSPEND_FREEZE
 10. all the devices are resumed.
 11. all the processes are unfrozen.
 12. system is back to working.
 
 Known Issue:
 The wakeup of this new PM_SUSPEND_FREEZE state may behave differently
 from the previous suspend state.
 Take ACPI platform for example, there are some GPEs that only enabled
 when the system is in sleep state, to wake the system backk from S3/S4.
 But we are not touching these GPEs during transition to PM_SUSPEND_FREEZE.
 This means we may lose some wake event.
 But on the other hand, as we do not disable all the Interrupts during
 PM_SUSPEND_FREEZE, we may get some extra wakeup Interrupts, that are
 not available for S3/S4.
 
 The patches has been tested on an old Sony laptop, and here are the results:
 
 Average Power:
 1. RPTM/idle for half an hour:
14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W
 2. Freeze for half an hour:
11W, 10.4W, 9.4W, 11.3W 10.5W
 3. RTPM/idle for three hours:
11.6W
 4. Freeze for three hours:
10W
 5. Suspend to Memory:
0.5~0.9W
 
 Average Resume Latency:
 1. RTPM/idle with a black screen: (From pressing keyboard to screen back)
Less than 0.2s
 2. Freeze: (From pressing power button to screen back)
2.50s
 3. Suspend to Memory: (From pressing power button to screen back)
4.33s
 
 From the results, we can see that all the platforms should benefit from
 this patch, even if it does not have Low Power S0.
 
fixed a build error when CONFIG_SUSPEND not set.
refreshed patch attached.

From e784933534b8fc00b4e7b52f3c34ea9e614e513e Mon Sep 17 00:00:00 2001
From: Zhang Rui rui.zh...@intel.com
Date: Mon, 14 Jan 2013 11:12:53 +0800
Subject: [PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE

PM_SUSPEND_FREEZE state is a general state that
does not need any platform specific support, it equals
frozen processes + suspended devices + idle processors.

Compared with PM_SUSPEND_MEMORY,
PM_SUSPEND_FREEZE saves less power
because the system is still in a running state.
PM_SUSPEND_FREEZE has less resume latency because it does not
touch BIOS, and the processors are in idle state.

Compared with RTPM/idle,
PM_SUSPEND_FREEZE saves more power as
1. the processor has longer sleep time because processes are frozen.
   The deeper c-state the processor supports, more power saving we can get.
2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get
   more power saving from the devices that does not have good RTPM support.

This state is useful for
1) platforms that do not have STR, or have a broken STR.
2) platforms that have an extremely low power idle state,
   which can be used to replace STR.

The following describes how PM_SUSPEND_FREEZE state works.
1. echo freeze  /sys/power/state
2. the processes are frozen.
3. all the devices are suspended.
4. all the processors are blocked by a wait queue
5. all the processors idles and enters (Deep) c-state.
6. an interrupt fires.
7. a processor is woken up and handles the irq.
8. if it is a general event,
   a) the irq handler runs and quites.
   b) goto step 4.
9. if it is a real wake event, say, power button pressing, keyboard touch, 
mouse moving,
   a) the irq handler runs and activate the wakeup source
   b) wakeup_source_activate() notifies the wait queue.
   c) system starts resuming from PM_SUSPEND_FREEZE
10. all the devices are