Re: [Intel-gfx] [PATCH v2 6/7] drm/i915: Remove redundant DSI PLL enabling
On Sat, 09 Nov 2013, Shobhit Kumar shobhit.ku...@intel.com wrote: DSI PLL will get configured during crtc_enable using -pre_pll_enable and no need to do in -mode_set Reviewed-by: Jani Nikula jani.nik...@intel.com Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com --- drivers/gpu/drm/i915/intel_dsi.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 9e67f78..4dccb4b 100644 --- a/drivers/gpu/drm/i915/intel_dsi.c +++ b/drivers/gpu/drm/i915/intel_dsi.c @@ -373,9 +373,6 @@ static void intel_dsi_mode_set(struct intel_encoder *intel_encoder) DRM_DEBUG_KMS(pipe %c\n, pipe_name(pipe)); - /* Update the DSI PLL */ - vlv_enable_dsi_pll(intel_encoder); - /* XXX: Location of the call */ band_gap_reset(dev_priv); -- 1.7.9.5 ___ 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 5/7] drm/i915: Reorganize the DSI enable/disable sequence
On Fri, Nov 15, 2013 at 10:27:25AM +0200, Jani Nikula wrote:
On Sat, 09 Nov 2013, Shobhit Kumar shobhit.ku...@intel.com wrote:
Basically ULPS handling during enable/disable has been moved to
pre_enable and post_disable phases. PLL and panel power disable
also has been moved to post_disable phase. The ULPS entry/exit
sequneces as suggested by HW team is as follows -
During enable time -
set DEVICE_READY -- Clear DEVICE_READY -- set DEVICE_READY
And during disable time to flush all FIFOs -
set ENTER_SLEEP -- EXIT_SLEEP -- ENTER_SLEEP
Also during disbale sequnece sub-encoder disable is moved to the end
after port is disabled.
v2: Based on comments from Ville
- Detailed epxlaination in the commit messgae
- Moved parameter changes out into another patch
- Backlight enabling will be a new patch
Signed-off-by: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 11
drivers/gpu/drm/i915/intel_dsi.c | 111
++
drivers/gpu/drm/i915/intel_dsi.h |2 +
3 files changed, 91 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index a2bbff9..55c16cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2433,6 +2433,17 @@ int vlv_freq_opcode(int ddr_freq, int val);
#define POSTING_READ(reg) (void)I915_READ_NOTRACE(reg)
#define POSTING_READ16(reg)(void)I915_READ16_NOTRACE(reg)
+#define I915_WRITE_BITS(reg, val, mask) \
+do { \
+ u32 tmp, data; \
+ tmp = I915_READ((reg)); \
+ tmp = ~(mask); \
+ data = (val) (mask); \
+ data = data | tmp; \
+ I915_WRITE((reg), data); \
+} while(0)
I would still prefer the explicit read, modify, and write in the code
instead of this, but it's a matter of taste I'll leave for Daniel to
call the shots on.
Yeah, this looks a bit funny. We could compute the tmp value once (where
the mask is mutliple times the same thing) and then just or in the right
bits. That should make the I915_WRITE calls fit ont on line, too, which
helps readability.
Also we put POSTING_READs before any waits to ensure the write has
actually landed. It's mostly documentation.
And while I'm at it: We generally frown upon readbacks of register value
and prefer to just keep track of things in software well enough. The
reason for that is that register readbacks allows us too much flexibility
in adding subtile state-depencies. Which long-term makes the code a real
pain to maintain.
-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] i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7
On Fri, Nov 15, 2013 at 12:39:32AM +0100, Daniel Vetter wrote: On Thu, Nov 14, 2013 at 05:40:36PM -0200, Rodrigo Vivi wrote: On Thu, Nov 14, 2013 at 09:36:10AM -0800, Olof Johansson wrote: On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote: From: Duncan Laurie dlau...@chromium.org We had been using a DMI table workaround to select the right frequency for devices, but this is fragile and must be updated with every new platform. Instead the default case when VBT is missing is changed to use 120MHz clock for LVDS SSC for these generations. The docs for 2010-Core, SandyBridge, and IvyBridge all indicate that the reference frequency for LVDS is 120MHz: 2010 Core http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf page 38 Reference Frequency: 120MHz for CRT and LVDS. 100MHz for the FDI. 2011 SandyBridge http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf page 33 Reference Frequency: 120MHz for CRT, HDMI, LVDS. 100MHz for the FDI. 2012 IvyBridge http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf page 27 Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI. Checked. You are right. And actually true even for HSW and BDW. 120 is the default and 100 is for test mode. Yeah, the patch predates HSW/BDW, so it was not mentioned. Signed-off-by: Duncan Laurie dlau...@chromium.org [olof: Fixup for recent base, switched from if/else to single call] Signed-off-by: Olof Johansson o...@lixom.net --- Daniel, This applies on top of -next, which I'm presuming is close to your for-3.13 base right now. It'd be good to see this go in since it's needed to boot on Chromebooks (with developer mode off), and is thus blocking testing next/mainline on a regular basis here. Thanks! -Olof drivers/gpu/drm/i915/intel_bios.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index 6dd622d733b9..e4fba39631a5 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -790,7 +790,12 @@ init_vbt_defaults(struct drm_i915_private *dev_priv) /* Default to using SSC */ dev_priv-vbt.lvds_use_ssc = 1; - dev_priv-vbt.lvds_ssc_freq = intel_bios_ssc_frequency(dev, 1); + /* + * Core/SandyBridge/IvyBridge use alternative (120MHz) reference + * clock for LVDS. + */ + dev_priv-vbt.lvds_ssc_freq = intel_bios_ssc_frequency(dev, + !HAS_PCH_SPLIT(dev)); I'm just not convinced this is the right way to fix this here. Mainly because for most of platforms the alternate is 100 and default is 120. The ideal in my opinion should be to invert the alternate inside ssc_freqeuncy function and use the exception, that is probably IS_PINEVIEW(dev)... Not sure though... just a guess since this alternate was implemented for pineview... Seeing the history of some of this code (changes, followed by reverts, etc), I wanted to stay conservative with what we know works from a few years in the field by now. Stay conservative is good, but what I don't like is just the inverted logic... or maybe just the alternate name. The vbt defaults are only used by Chromebooks, as far as I know, so it's not a code path shared with other platforms today. Are you sure? I don't know who is really setting vbt or going to defaults, but it is possible to have any one using it right now... anyway another reason to stay conservative... Also, the ssc_freq bit from the vbios table is passed into this function, so I don't think there's much point in reversing the logic in there just for one of the two code paths. yeah, maybe just the name alternate is killing me here... Finally, from elsewhere in the same file: /* * The genX designation typically refers to the render engine, so render * capability related checks should use IS_GEN, while display and other checks * have their own (e.g. HAS_PCH_SPLIT for ILK+ display, IS_foo for particular * chips, etc.). */ with this I agree.. Since this is display and not rendering related, that seems like the right thing to base it on instead of generation tests. I'm open for suggestions on improvements though, of course. I don't have a real suggestion here... only bikesheds... maybe on the alternate name ;) But either way, it seems to work and right since default is 120 for those platforms... So, feel free to use: Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com Queued
Re: [Intel-gfx] [PATCH] drm/i915: Prevent NULL after failed PPGTT
On Thu, Nov 14, 2013 at 05:01:44PM -0800, Ben Widawsky wrote: If an object was bound in the ppgtt, and we do a GPU reset, but the PPGTT was not brought back up on reset, trying to unbind the object later will result in a NULL ptr. Ideally this (failed PPGTT) should never happen, but it is allowed in the code, and therefore we should prevent the OOPS. Since Broadwell hangs/reset is still under development, and apparently so is aliasing PPGTT after rest, this helps alleviate some of the pain. NOTE: With the coming PPGTT patches this can't ever occur since there if PPGTT is supposed to come up, and doesn't the driver will fail to load (since it will make context loading fail). Here is an example splat: [ 588.795571] ---[ end trace f23239922ecdffbc ]--- [ 598.427072] [drm] stuck on render ring [ 598.473116] [drm] GPU crash dump saved to /sys/class/drm/card0/error [ 598.550946] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 598.663996] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI - DRM/Intel [ 598.772830] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 598.891172] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 599.006668] [drm] Simulated gpu hang, resetting stop_rings [ 599.084004] [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. [ 599.204258] [drm] PPGTT enable failed. This is not fatal, but unexpected [ 599.287287] BUG: unable to handle kernel NULL pointer dereference at 0108 [ 599.389563] IP: [a0559794] i915_ppgtt_unbind_object+0x14/0x60 [i915] [ 599.484426] PGD 34ab6067 PUD 50b2a067 PMD 0 [ 599.542964] Oops: [#1] PREEMPT SMP [ 599.597171] Modules linked in: i915 drm_kms_helper drm intel_gtt agpgart i2c_algo_bit i2c_core netconsole configfs ext4 x86_pkg_temp_thermal coretemp crc16 mbcache kvm_intel jbd2 kvm ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd microcode serio_raw evdev thermal fan battery e1000e acpi_cpufreq video ptp button pps_core ac processor snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_timer snd soundcore hid_generic usbhid hid btrfs libcrc32c xor raid6_pq sd_mod ehci_pci ehci_hcd ahci libahci crc32c_intel libata usbcore scsi_mod usb_common [ 600.268119] CPU: 0 PID: 2612 Comm: kms_flip Tainted: GW 3.12.0-BEN+ #38 [ 600.366889] Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1, BIOS BDW-E1R1.86C.0048.R02.1310291000 10/29/2013 [ 600.527990] task: 88009d28b0c0 ti: 88003b5d4000 task.ti: 88003b5d4000 [ 600.626121] RIP: 0010:[a0559794] [a0559794] i915_ppgtt_unbind_object+0x14/0x60 [i915] [ 600.750986] RSP: 0018:88003b5d5ca0 EFLAGS: 00010202 [ 600.822380] RAX: 0004 RBX: 88008eac5a40 RCX: 00fe [ 600.916281] RDX: RSI: 88008eac5a40 RDI: 88008eac5a40 [ 601.010181] RBP: 88003b5d5cb8 R08: R09: [ 601.104083] R10: R11: R12: [ 601.197983] R13: 88008eac5b30 R14: 880145208000 R15: 88008eac5ac8 [ 601.291686] FS: 7fabc555a8c0() GS:88014f40() knlGS: [ 601.397339] CS: 0010 DS: ES: CR0: 80050033 [ 601.474153] CR2: 0108 CR3: 8eadd000 CR4: 003407f0 [ 601.568035] Stack: [ 601.599051] 88008eac5a40 88005cb96000 88008eac5b30 88003b5d5cf0 [ 601.696409] a055003f 88008eac5a40 88005cb96000 88008eac5b30 [ 601.793636] 880145208000 88008eac5ac8 88003b5d5d30 a05513fe [ 601.890889] Call Trace: [ 601.927323] [a055003f] i915_vma_unbind+0x28f/0x340 [i915] [ 602.011520] [a05513fe] i915_gem_free_object+0x9e/0x340 [i915] [ 602.100135] [810b81cd] ? trace_hardirqs_on+0xd/0x10 [ 602.178010] [a04c248a] drm_gem_object_free+0x2a/0x30 [drm] [ 602.263249] [a04c29fa] drm_gem_object_handle_unreference_unlocked+0x11a/0x130 [drm] [ 602.375214] [a04c2ae6] drm_gem_handle_delete+0xd6/0x1d0 [drm] [ 602.463759] [a04c3358] drm_gem_close_ioctl+0x28/0x30 [drm] [ 602.549031] [a04c0d92] drm_ioctl+0x502/0x640 [drm] [ 602.625820] [8115ac70] ? might_fault+0xa0/0xb0 [ 602.698152] [8115ac27] ? might_fault+0x57/0xb0 [ 602.770831] [8100f0ec] ? __restore_xstate_sig+0x13c/0x600 [ 602.855035] [811bb6c5] do_vfs_ioctl+0x305/0x530 [ 602.928680] [811c73a7] ? fget_light+0x387/0x4f0 [ 603.001415] [811bb971] SyS_ioctl+0x81/0xa0 [ 603.069506] [814dd6d6] system_call_fastpath+0x1a/0x1f [ 603.148332] Code: 89 e7 89
Re: [Intel-gfx] [PATCH v2 2/7] drm/i915: Use FLISDSI interface for band gap reset
On Sat, 09 Nov 2013, Shobhit Kumar shobhit.ku...@intel.com wrote:
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Yogesh Mohan Marimuthu yogesh.mohan.marimu...@intel.com
Reviewed-by: Jani Nikulajani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dsi.c | 47
++---
drivers/gpu/drm/i915/intel_sideband.c | 14 ++
4 files changed, 25 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b12d942..a2bbff9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2408,6 +2408,8 @@ u32 intel_sbi_read(struct drm_i915_private *dev_priv,
u16 reg,
enum intel_sbi_destination destination);
void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
enum intel_sbi_destination destination);
+u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
+void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
This hunk has a (trivial) conflict now, needs a rebase.
Jani.
int vlv_gpu_freq(int ddr_freq, int val);
int vlv_freq_opcode(int ddr_freq, int val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3f303ba..6236926 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -356,6 +356,7 @@
#define IOSF_PORT_CCK 0x14
#define IOSF_PORT_CCU 0xA9
#define IOSF_PORT_GPS_CORE 0x48
+#define IOSF_PORT_FLISDSI 0x1B
#define VLV_IOSF_DATA(VLV_DISPLAY_BASE +
0x2104)
#define VLV_IOSF_ADDR(VLV_DISPLAY_BASE +
0x2108)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c
b/drivers/gpu/drm/i915/intel_dsi.c
index 61267e2..8dc9a38 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -37,49 +37,18 @@
static const struct intel_dsi_device intel_dsi_devices[] = {
};
-
-static void vlv_cck_modify(struct drm_i915_private *dev_priv, u32 reg, u32
val,
-u32 mask)
-{
- u32 tmp = vlv_cck_read(dev_priv, reg);
- tmp = ~mask;
- tmp |= val;
- vlv_cck_write(dev_priv, reg, tmp);
-}
-
-static void band_gap_wa(struct drm_i915_private *dev_priv)
+static void band_gap_reset(struct drm_i915_private *dev_priv)
{
mutex_lock(dev_priv-dpio_lock);
- /* Enable bandgap fix in GOP driver */
- vlv_cck_modify(dev_priv, 0x6D, 0x0001, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6E, 0x0001, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6F, 0x0001, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x00, 0x8000, 0x8000);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x00, 0x, 0x8000);
- msleep(20);
-
- /* Turn Display Trunk on */
- vlv_cck_modify(dev_priv, 0x6B, 0x0002, 0x0003);
- msleep(20);
-
- vlv_cck_modify(dev_priv, 0x6C, 0x0002, 0x0003);
- msleep(20);
-
- vlv_cck_modify(dev_priv, 0x6D, 0x0002, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6E, 0x0002, 0x0003);
- msleep(20);
- vlv_cck_modify(dev_priv, 0x6F, 0x0002, 0x0003);
+ vlv_flisdsi_write(dev_priv, 0x08, 0x0001);
+ vlv_flisdsi_write(dev_priv, 0x0F, 0x0005);
+ vlv_flisdsi_write(dev_priv, 0x0F, 0x0025);
+ udelay(150);
+ vlv_flisdsi_write(dev_priv, 0x0F, 0x);
+ vlv_flisdsi_write(dev_priv, 0x08, 0x);
mutex_unlock(dev_priv-dpio_lock);
-
- /* Need huge delay, otherwise clock is not stable */
- msleep(100);
}
static struct intel_dsi *intel_attached_dsi(struct drm_connector *connector)
@@ -363,7 +332,7 @@ static void intel_dsi_mode_set(struct intel_encoder
*intel_encoder)
vlv_enable_dsi_pll(intel_encoder);
/* XXX: Location of the call */
- band_gap_wa(dev_priv);
+ band_gap_reset(dev_priv);
/* escape clock divider, 20MHz, shared for A and C. device ready must be
* off when doing this! txclkesc? */
diff --git a/drivers/gpu/drm/i915/intel_sideband.c
b/drivers/gpu/drm/i915/intel_sideband.c
index 9944d81..f15e57e 100644
--- a/drivers/gpu/drm/i915/intel_sideband.c
+++ b/drivers/gpu/drm/i915/intel_sideband.c
@@ -242,3 +242,17 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
u16 reg, u32 value,
return;
}
}
+
+u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg)
+{
+ u32 val = 0;
+ vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI,
+ DPIO_OPCODE_REG_READ, reg, val);
+ return val;
+}
+
+void
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon
On Fri, Nov 15, 2013 at 01:29:30AM +0100, Daniel Vetter wrote: On Thu, Nov 14, 2013 at 04:04:24PM -0800, Jesse Barnes wrote: Retrieve current framebuffer config info from the regs and create an fb object for the buffer the BIOS or boot loader left us. This should allow for smooth transitions to userspace apps once we finish the initial configuration construction. v2: check for non-native modes and adjust (Jesse) fixup aperture and cmap frees (Imre) use unlocked unref if init_bios fails (Jesse) fix curly brace around DSPADDR check (Imre) comment failure path for pin_and_fence (Imre) v3: fixup fixup of aperture frees (Chris) v4: update to current bits (locking pin_and_fence hack) (Jesse) v5: move fb config fetch to display code (Jesse) re-order hw state readout on initial load to suit fb inherit (Jesse) re-add pin_and_fence in fbdev code to make sure we refcount properly (Je v6: rename to plane_config (Daniel) check for valid object when initializing BIOS fb (Jesse) split from plane_config readout and other display changes (Jesse) drop use_bios_fb option (Chris) update comments (Jesse) rework fbdev_init_bios for clarity (Jesse) drop fb obj ref under lock (Chris) Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Just for the record I'm still freaked out who we're supposed to keep this working. But since all the ideas I could come up are somewhere between groos and that's not going to work I'm leaning towards ignoring it. This used to disable the outputs attached to the current bios fb if we failed to takeover the fb. This is required to prevent the machine reading out garbage whilst we modify the GTT and potentially hanging the GPU. This is also a regression from about 3.2. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] bdw-fixes for 3.13
Hi Dave, As promised bdw fixes come separate for now. Just a few minior things. Cheers, Daniel The following changes since commit ad40f83f5a89f6d723fd4db424b531f8dd7d3b49: Merge branch 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux into drm-next (2013-11-14 09:53:15 +1000) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel bdw-fixes for you to fetch changes up to 596cc11e7a4a89bf6c45f955402d0bd0c7d51f13: drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell (2013-11-14 09:33:12 +0100) Ben Widawsky (7): drm/i915/bdw: Add BDW to ULT macro drm/i915/bdw: GEN8 backlight support drm/i915/bdw: Do gen6 style reset for gen8 drm/i915/bdw: Free correct number of ppgtt pages drm/i915/bdw: Add comment about gen8 HWS PGA drm/i915/bdw: Limit GTT to 2GB drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell drivers/gpu/drm/i915/i915_drv.h | 7 ++- drivers/gpu/drm/i915/i915_gem_gtt.c | 9 +++-- drivers/gpu/drm/i915/intel_panel.c | 26 +++--- drivers/gpu/drm/i915/intel_pm.c | 18 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + drivers/gpu/drm/i915/intel_uncore.c | 1 + 6 files changed, 55 insertions(+), 7 deletions(-) -- 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
[Intel-gfx] [PATCH] drm/i915: Fix module unloading with DRM_I915_UMS=n
Oops, makes testing early boot failures in i915.ko a bit more pain, so
let's fix it.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c2e00ed23195..d9e5c6fc52ea 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -982,6 +982,8 @@ static struct pci_driver i915_pci_driver = {
.driver.pm = i915_pm_ops,
};
+bool i915_no_driver_loaded;
+
static int __init i915_init(void)
{
driver.num_ioctls = i915_max_ioctl;
@@ -1011,6 +1013,7 @@ static int __init i915_init(void)
driver.get_vblank_timestamp = NULL;
#ifndef CONFIG_DRM_I915_UMS
/* Silently fail loading to not upset userspace. */
+ i915_no_driver_loaded = true;
return 0;
#endif
}
@@ -1020,6 +1023,9 @@ static int __init i915_init(void)
static void __exit i915_exit(void)
{
+ if (i915_no_driver_loaded)
+ return;
+
drm_pci_exit(driver, i915_pci_driver);
}
--
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] drm/i915: Fix module unloading with DRM_I915_UMS=n
On Fri, Nov 15, 2013 at 11:28:39AM +0100, Daniel Vetter wrote: Oops, makes testing early boot failures in i915.ko a bit more pain, so let's fix it. You already have a static driver structure, why not take advantage of that here? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/dp: add eDP 1.2 display control DPCD register definitions
Preparing for the future eDP panels. Signed-off-by: Jani Nikula jani.nik...@intel.com --- include/drm/drm_dp_helper.h | 29 + 1 file changed, 29 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index a92c375..e2dbde6 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -100,6 +100,9 @@ # define DP_I2C_SPEED_1M 0x20 #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */ +# define DP_ALTERNATE_SCRAMBLER_RESET_CAP (1 0) +# define DP_FRAMING_CHANGE_CAP (1 1) +# define DP_DPCD_DISPLAY_CONTROL_CAP(1 3) /* eDP 1.2 */ #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ /* Multiple stream transport */ @@ -291,6 +294,32 @@ # define DP_SET_POWER_D00x1 # define DP_SET_POWER_D30x2 +#define DP_EDP_REV 0x700 /* eDP 1.2 */ + +#define DP_EDP_GENERAL_CAPABILITY_REGISTER_1 0x701 +#define DP_EDP_BACKLIGHT_ADJUSTMENT_CAPABILITY_REGISTER0x702 +#define DP_EDP_GENERAL_CAPABILITY_REGISTER_2 0x703 + +#define DP_EDP_DISPLAY_CONTROL_REGISTER 0x720 +#define DP_EDP_BACKLIGHT_MODE_SET_REGISTER 0x721 +#define DP_EDP_BACKLIGHT_BRIGHTNESS_MSB 0x722 +#define DP_EDP_BACKLIGHT_BRIGHTNESS_LSB 0x723 +#define DP_EDP_PWMGEN_BIT_COUNT 0x724 +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725 +#define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726 +#define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727 +#define DP_EDP_BACKLIGHT_FREQ_SET 0x728 + +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB 0x72a +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID 0x72b +#define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_LSB 0x72c +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MSB 0x72d +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_MID 0x72e +#define DP_EDP_BACKLIGHT_FREQ_CAP_MAX_LSB 0x72f + +#define DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET 0x732 +#define DP_EDP_DBC_MAXIMUM_BRIGHTNESS_SET 0x733 + #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ # define DP_PSR_LINK_CRC_ERROR (1 0) # define DP_PSR_RFB_STORAGE_ERROR (1 1) -- 1.7.9.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/dp: check eDP display control capability registers
Debug print the capabilities, and flag an error if the panel does not
support adjusting backlight through the BL_PWM_DIM pin, requiring
backlight control through DPCD.
I haven't seen such panels yet, but it's a matter of time. Give
ourselves a reminder when we need to fix this for real.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cbf33be..ea4f3d1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2816,6 +2816,20 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
dev_priv-psr.sink_support = true;
DRM_DEBUG_KMS(Detected EDP PSR Panel.\n);
}
+
+ if (intel_dp-dpcd[DP_EDP_CONFIGURATION_CAP]
+ DP_DPCD_DISPLAY_CONTROL_CAP) {
+ u8 ctrl[4] = { 0 };
+
+ intel_dp_aux_native_read(intel_dp, DP_EDP_REV,
+ctrl, sizeof(ctrl));
+ DRM_DEBUG_KMS(eDP DPCD CTRL %02x %02x %02x %02x\n,
+ ctrl[0], ctrl[1], ctrl[2], ctrl[3]);
+
+ /* We don't support DPCD backlight control yet. */
+ if (ctrl[0] (ctrl[1] 1) !(ctrl[2] 1))
+ DRM_ERROR(eDP AUX backlight control only\n);
+ }
}
if (!(intel_dp-dpcd[DP_DOWNSTREAMPORT_PRESENT]
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Workaround for flicker with panning on the i830 - found a way for tiled displays
Hi Daniel, hi others, did even more experiments. I guess I understand now better. Indeed, the trouble seems to be the watermark levels. I played more with all that, and the real culprit seems to be the FW_BLC register controlling the watermarks. On the i830 with the current settings, it is defined to be 0x1080304 which sets the watermark a bit too low. If I set it to 0x1080306 instead, I get a stable display in all panning positions (hurray!). I would like to fix this, but I guess I would need to understand the logic a little bit better. At the time being, you probably better put the linear frame buffer workaround on hold, it looks I really got something here. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/ddi: set sink to power down mode on dp disable
Similar to
commit fdbc3b1f639bb2cbfb32c612b2699e0ba373317d
Author: Jani Nikula jani.nik...@intel.com
Date: Tue Nov 12 17:10:13 2013 +0200
drm/i915/dp: set sink to power down mode on dp disable
but for DDI, where we've never done this.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
UNTESTED!
---
drivers/gpu/drm/i915/intel_ddi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1591576..6a63a09 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1158,9 +1158,10 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder)
if (wait)
intel_wait_ddi_buf_idle(dev_priv, port);
- if (type == INTEL_OUTPUT_EDP) {
+ if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_panel_vdd_on(intel_dp);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
ironlake_edp_panel_off(intel_dp);
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/ddi: set sink to power down mode on dp disable
Similar to
commit fdbc3b1f639bb2cbfb32c612b2699e0ba373317d
Author: Jani Nikula jani.nik...@intel.com
Date: Tue Nov 12 17:10:13 2013 +0200
drm/i915/dp: set sink to power down mode on dp disable
but for DDI, where we've never done this.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
UNTESTED!
---
drivers/gpu/drm/i915/intel_ddi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1591576..6a63a09 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1158,9 +1158,10 @@ static void intel_ddi_post_disable(struct intel_encoder
*intel_encoder)
if (wait)
intel_wait_ddi_buf_idle(dev_priv, port);
- if (type == INTEL_OUTPUT_EDP) {
+ if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
ironlake_edp_panel_vdd_on(intel_dp);
+ intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
ironlake_edp_panel_off(intel_dp);
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Workaround for flicker with panning on the i830 - found a way for tiled displays
On Fri, Nov 15, 2013 at 02:16:11PM +0100, Thomas Richter wrote: Hi Daniel, hi others, did even more experiments. I guess I understand now better. Indeed, the trouble seems to be the watermark levels. I played more with all that, and the real culprit seems to be the FW_BLC register controlling the watermarks. On the i830 with the current settings, it is defined to be 0x1080304 which sets the watermark a bit too low. If I set it to 0x1080306 instead, I get a stable display in all panning positions (hurray!). I would like to fix this, but I guess I would need to understand the logic a little bit better. At the time being, you probably better put the linear frame buffer workaround on hold, it looks I really got something here. Gosh, should have read the code more closely. We have a totally botched wm setup on i830M - the watermark code for the 2nd pipe is just not there! I'll try to wip up a patch to fix this. -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] Workaround for flicker with panning on the i830 - found a way for tiled displays
Am 15.11.2013 16:41, schrieb Daniel Vetter: Gosh, should have read the code more closely. We have a totally botched wm setup on i830M - the watermark code for the 2nd pipe is just not there! (-: Guess that explains something. Just disregard my earlier patch, simply superfluous. In the meantime, I recompiled the code and *decreased* the latency from 5000 to 3000, then getting a stable image, even the boot console is then stable (has never been before). Its still off by half a screen, but no longer flickering left and right. However, what I do not understand about the watermark computation is that a *lower* latency results in a *higher* number of entries in the FIFO. Shouldn't this quite the reverse? In specific, I do not understand the subtraction in intel_calculate_wm, line 1058. Anyhow, I let you proceed with the patch and I'm ready and happy to test it. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: i830M has watermarks like i855
So shuffle the checks around a bit. Also give all the structs and
functions proper prefixes: i830_ for the dual-pipe mobile platforms
and i845_ for the two single-pipe desktop platforms.
Note that the max fifo value isn't actually correct for the i830M, but
since we don't frob the fifo split we don't actually need it. This is
different for some gen3 devices where we need the full fifo for self
refresh mode.
Cc: Thomas Richter rich...@rus.uni-stuttgart.de
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 53 +++--
1 file changed, 19 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 172efa0bfb86..64d4832b56cc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -817,7 +817,7 @@ static int i9xx_get_fifo_size(struct drm_device *dev, int
plane)
return size;
}
-static int i85x_get_fifo_size(struct drm_device *dev, int plane)
+static int i830_get_fifo_size(struct drm_device *dev, int plane)
{
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t dsparb = I915_READ(DSPARB);
@@ -850,21 +850,6 @@ static int i845_get_fifo_size(struct drm_device *dev, int
plane)
return size;
}
-static int i830_get_fifo_size(struct drm_device *dev, int plane)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
- uint32_t dsparb = I915_READ(DSPARB);
- int size;
-
- size = dsparb 0x7f;
- size = 1; /* Convert to cachelines */
-
- DRM_DEBUG_KMS(FIFO size - (0x%08x) %s: %d\n, dsparb,
- plane ? B : A, size);
-
- return size;
-}
-
/* Pineview has different values for various configs */
static const struct intel_watermark_params pineview_display_wm = {
PINEVIEW_DISPLAY_FIFO,
@@ -943,14 +928,14 @@ static const struct intel_watermark_params i915_wm_info =
{
2,
I915_FIFO_LINE_SIZE
};
-static const struct intel_watermark_params i855_wm_info = {
+static const struct intel_watermark_params i830_wm_info = {
I855GM_FIFO_SIZE,
I915_MAX_WM,
1,
2,
I830_FIFO_LINE_SIZE
};
-static const struct intel_watermark_params i830_wm_info = {
+static const struct intel_watermark_params i845_wm_info = {
I830_FIFO_SIZE,
I915_MAX_WM,
1,
@@ -1567,7 +1552,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
else if (!IS_GEN2(dev))
wm_info = i915_wm_info;
else
- wm_info = i855_wm_info;
+ wm_info = i830_wm_info;
fifo_size = dev_priv-display.get_fifo_size(dev, 0);
crtc = intel_get_crtc_for_plane(dev, 0);
@@ -1674,7 +1659,7 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
}
}
-static void i830_update_wm(struct drm_crtc *unused_crtc)
+static void i845_update_wm(struct drm_crtc *unused_crtc)
{
struct drm_device *dev = unused_crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1689,7 +1674,7 @@ static void i830_update_wm(struct drm_crtc *unused_crtc)
adjusted_mode = to_intel_crtc(crtc)-config.adjusted_mode;
planea_wm = intel_calculate_wm(adjusted_mode-crtc_clock,
- i830_wm_info,
+ i845_wm_info,
dev_priv-display.get_fifo_size(dev, 0),
4, latency_ns);
fwater_lo = I915_READ(FW_BLC) ~0xfff;
@@ -5990,21 +5975,21 @@ void intel_init_pm(struct drm_device *dev)
dev_priv-display.update_wm = i9xx_update_wm;
dev_priv-display.get_fifo_size = i9xx_get_fifo_size;
dev_priv-display.init_clock_gating = gen3_init_clock_gating;
- } else if (IS_I865G(dev)) {
- dev_priv-display.update_wm = i830_update_wm;
- dev_priv-display.init_clock_gating = i85x_init_clock_gating;
- dev_priv-display.get_fifo_size = i830_get_fifo_size;
- } else if (IS_I85X(dev)) {
- dev_priv-display.update_wm = i9xx_update_wm;
- dev_priv-display.get_fifo_size = i85x_get_fifo_size;
- dev_priv-display.init_clock_gating = i85x_init_clock_gating;
- } else {
- dev_priv-display.update_wm = i830_update_wm;
- dev_priv-display.init_clock_gating = i830_init_clock_gating;
- if (IS_845G(dev))
+ } else if (IS_GEN2(dev)) {
+ if (INTEL_INFO(dev)-num_pipes == 1) {
+ dev_priv-display.update_wm = i845_update_wm;
dev_priv-display.get_fifo_size = i845_get_fifo_size;
- else
+ } else {
+ dev_priv-display.update_wm = i9xx_update_wm;
dev_priv-display.get_fifo_size = i830_get_fifo_size;
+ }
+
+ if
[Intel-gfx] [PATCH] drm/i915: Fix module unloading with DRM_I915_UMS=n
Oops, makes testing early boot failures in i915.ko a bit more pain, so
let's fix it.
v2: We already have a bit of static storage to track this (Chris).
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c2e00ed23195..72fc9e33c78c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1020,6 +1020,11 @@ static int __init i915_init(void)
static void __exit i915_exit(void)
{
+#ifndef CONFIG_DRM_I915_UMS
+ if (!(driver.driver_features DRIVER_MODESET))
+ return; /* Never loaded a driver. */
+#endif
+
drm_pci_exit(driver, i915_pci_driver);
}
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [igt] Making the test-suite easier to run
The objective of this series is to make the test-suite easier to run by embedding a copy a piglit and providing porcelain on top of it in the form of a makefile target. Beside python, there's no external dependency to run the test suite after this series. The provided makefile target runs the full test suite. I'm still interested in providing, as a follow-up of this work, shorcuts for subsets of the testsuite that can be useful for developpers, subset what we would maintain in tree. For instance: - tests selected by topic: running gem_.* Vs kms_.* Vs pm_.* (or maybe when running, say, gt tests, exlude ^kms_.* ^pm_.* so we still still a lot of the other tests (core_, drm_, ...) - quick subtests (where we disable long running stress, race, ... tests) patches 21-23 are something a bit different, try to pave the way for quick runs (by really the first tiny step). The README has been updated and I copy/paste it here the documentation for what would be the new way to run tests: After having compiled the tests, one can run the test-suite with: $ sudo make run-tests make run-tests create a $date-piglit-results.$n directory with the results of the run. More specifically: - $date-piglit-results.$n/main JSON file with the test results - $date-piglit-results.$n/html/index.html HTML summary of the run Where $date is the date formated with `date +%Y%m%d` and $n the nth run of the day. PIGLIT_FLAGS can be used to give options to the underlying piglit runner. For instance, to exclude test matching '^kms_': $ sudo make run-tests PIGLIT_FLAGS=-x ^kms_ For the list of piglit options, run: $ ./piglit/piglit-run.py -h Another useful feature is to be able to resume an interrupted run. To do that, make run-tests needs to know which run we are talking about: $ sudo make run-tests RESUME=$date-piglit-results.$n or, more succinctly: $ sudo make run-tests R=$date-piglit-results.$n It's possible to combine PIGLIT_FLAGS and RESUME. This is useful to resume runs where a specific test deterministically hang the machine: $ sudo make run-tests PIGLIT_FLAGS=-x drv_module_reload R=$date-piglit-results.$n HTH, -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/23] piglit: Adapt igt.tests to discover the tests directory itself
Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- piglit/tests/igt.tests | 16 +++- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/piglit/tests/igt.tests b/piglit/tests/igt.tests index f388492..16e4586 100644 --- a/piglit/tests/igt.tests +++ b/piglit/tests/igt.tests @@ -31,20 +31,10 @@ from os import path from framework.core import testBinDir, TestProfile from framework.exectest import ExecTest -# -# IGTTest: Execute an intel-gpu-tools test -# -# To use this, create an igt symlink in piglit/bin which points to the root -# of the intel-gpu-tools sources with the compiled tests. Piglit will -# automatically add all tests into the 'igt' category. -# - -if not os.path.exists(os.path.join(testBinDir, 'igt')): -print igt symlink not found! -sys.exit(0) - # Chase the piglit/bin/igt symlink to find where the tests really live. -igtTestRoot = path.join(path.realpath(path.join(testBinDir, 'igt')), 'tests') +piglitRoot = path.join(path.dirname(path.realpath(__file__)), os.pardir) +igtRoot = path.join(piglitRoot, os.pardir) +igtTestRoot = path.join(igtRoot, 'tests') profile = TestProfile() -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/23] piglit: Import igt.tests from piglit
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
piglit/tests/igt.tests | 125 +
1 file changed, 125 insertions(+)
create mode 100644 piglit/tests/igt.tests
diff --git a/piglit/tests/igt.tests b/piglit/tests/igt.tests
new file mode 100644
index 000..f388492
--- /dev/null
+++ b/piglit/tests/igt.tests
@@ -0,0 +1,125 @@
+#
+# Copyright (c) 2012 Intel Corporation
+#
+# Permission is hereby granted, free of charge, to any person
+# obtaining a copy of this software and associated documentation
+# files (the Software), to deal in the Software without
+# restriction, including without limitation the rights to use,
+# copy, modify, merge, publish, distribute, sublicense, and/or
+# sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following
+# conditions:
+#
+# This permission notice shall be included in all copies or
+# substantial portions of the Software.
+#
+# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY
+# KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
+# WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
+# PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHOR(S) BE
+# LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
+# OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+
+import os
+import re
+import sys
+import subprocess
+
+from os import path
+from framework.core import testBinDir, TestProfile
+from framework.exectest import ExecTest
+
+#
+# IGTTest: Execute an intel-gpu-tools test
+#
+# To use this, create an igt symlink in piglit/bin which points to the root
+# of the intel-gpu-tools sources with the compiled tests. Piglit will
+# automatically add all tests into the 'igt' category.
+#
+
+if not os.path.exists(os.path.join(testBinDir, 'igt')):
+print igt symlink not found!
+sys.exit(0)
+
+# Chase the piglit/bin/igt symlink to find where the tests really live.
+igtTestRoot = path.join(path.realpath(path.join(testBinDir, 'igt')), 'tests')
+
+profile = TestProfile()
+
+class IGTTest(ExecTest):
+def __init__(self, binary, arguments=[]):
+ExecTest.__init__(self, [path.join(igtTestRoot, binary)] + arguments)
+self.timeout = 60*20 # 20 minutes deadline by default
+
+def interpretResult(self, out, returncode, results, dmesg):
+if returncode == 0:
+results['result'] = 'dmesg-warn' if dmesg != '' else 'pass'
+elif returncode == 77:
+results['result'] = 'skip'
+else:
+results['result'] = 'dmesg-fail' if dmesg != '' else 'fail'
+return out
+def run(self, env):
+env.dmesg = True
+return ExecTest.run(self, env)
+
+def listTests(listname):
+oldDir = os.getcwd()
+try:
+os.chdir(igtTestRoot)
+proc = subprocess.Popen(
+['make', listname ],
+stdout=subprocess.PIPE,
+stderr=subprocess.PIPE,
+env=os.environ.copy(),
+universal_newlines=True
+)
+out, err = proc.communicate()
+returncode = proc.returncode
+finally:
+os.chdir(oldDir)
+
+lines = out.split('\n')
+found_header = False
+progs =
+
+for line in lines:
+if found_header:
+progs = line.split( )
+break
+
+if TESTLIST in line:
+found_header = True;
+
+return progs
+
+singleTests = listTests(list-single-tests)
+
+for test in singleTests:
+profile.test_list[path.join('igt', test)] = IGTTest(test)
+
+def addSubTestCases(test):
+proc = subprocess.Popen(
+[path.join(igtTestRoot, test), '--list-subtests' ],
+stdout=subprocess.PIPE,
+stderr=subprocess.PIPE,
+env=os.environ.copy(),
+universal_newlines=True
+)
+out, err = proc.communicate()
+returncode = proc.returncode
+
+subtests = out.split(\n)
+
+for subtest in subtests:
+if subtest == :
+continue
+profile.test_list[path.join('igt', test, subtest)] = \
+IGTTest(test, ['--run-subtest', subtest])
+
+multiTests = listTests(list-multi-tests)
+
+for test in multiTests:
+addSubTestCases(test)
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/23] piglit: Support resuming from a previous run
It can happen that the machine hard hangs in one of tests, say,
drv_module_reload. We really want to support resuming the run in that
case (probably excluding the faulty test as well). This commit adds an
easy way to do that:
sudo make run-tests PIGLIT_FLAGS=-x module_reload
RESUME=20131114-piglit-results.1
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
Makefile.am | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 471dd3d..5742b82 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -58,9 +58,18 @@ TEST_TARGETS := #
TEST_TARGETS += run-test
run-tests:
- @source $(srcdir)/scripts/build-piglit.sh \
- output=$$(igt_result_directory) \
- $(PIGLIT) $(IGT_TESTS) $$output \
+ @if [ -n $(RESUME) ]; then \
+ [ ! -f $(RESUME)/main ] { \
+ echo $(RESUME) is not a valid piglit project; \
+ exit 1; \
+ }; \
+ output=$(RESUME); \
+ echo Resuming $(RESUME)...; \
+ PIGLIT_FLAGS=--resume $$PIGLIT_FLAGS; \
+ else \
+ source $(srcdir)/scripts/build-piglit.sh \
+ output=$$(igt_result_directory); \
+ fi; \
$(PIGLIT) $${PIGLIT_FLAGS} $(IGT_TESTS) $$output \
$(PIGLIT_HTML) $$output/html $$output/main \
$(PIGLIT_SUMMARY) $$output/main
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/23] piglit: Add a script to synchronise the piglit test runner
The goal is to to remove the need to clone and compile piglit to run a
piglit enabled igt. Compiling piglit is not actually needed and we can
just grab the python files from a reference checktout.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
piglit/sync-from-piglit | 24
1 file changed, 24 insertions(+)
create mode 100755 piglit/sync-from-piglit
diff --git a/piglit/sync-from-piglit b/piglit/sync-from-piglit
new file mode 100755
index 000..20a95ff
--- /dev/null
+++ b/piglit/sync-from-piglit
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+PIGLIT_DIR=$1
+BASE_DIR=$(cd $(dirname $0); pwd -P)
+EXCLUDE_FILE=$BASE_DIR/sync-exclude
+
+[ -z $PIGLIT_DIR ] {
+ echo Error: You must specify the piglit directory to sync from
+ exit 1
+}
+
+cat EOF $EXCLUDE_FILE
+tests
+*.pyc
+*_test.py
+EOF
+
+rsync -rtv --exclude-from $EXCLUDE_FILE\
+ $PIGLIT_DIR/framework \
+ $PIGLIT_DIR/templates \
+ $PIGLIT_DIR/piglit-*.py \
+ $BASE_DIR
+
+rm -f $EXCLUDE_FILE
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/23] pm_pc8: Use SLOW_QUICK() with the number of rounds
igt has some test suite wide support to specify slow/quick numbers of
rounds with the SLOW_QUICK() macro.
This allows us to run the tests with IGT_QUICK=1 and get the fast
version of tests and provide a unified interface.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
tests/pm_pc8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/pm_pc8.c b/tests/pm_pc8.c
index efeae21..7003d5a 100644
--- a/tests/pm_pc8.c
+++ b/tests/pm_pc8.c
@@ -1280,7 +1280,7 @@ static void gem_execbuf_stress_subtest(int rounds, int
wait_flags)
int main(int argc, char *argv[])
{
- int rounds = 50;
+ int rounds = SLOW_QUICK(50, 10);
igt_subtest_init(argc, argv);
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/23] piglit: Update the README file with the new way of running tests
Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- README | 54 -- 1 file changed, 32 insertions(+), 22 deletions(-) diff --git a/README b/README index 246e24c..021888f 100644 --- a/README +++ b/README @@ -24,38 +24,48 @@ tests/ changes. Hopefully this can cover the relevant cases we need to worry about, including backwards compatibility. - Note: The old automake based testrunner had to be scraped due to - upstream changes which broke dynamic creation of the test list. Of - course it is still possible to directly run tests, even when not always - limiting tests to specific subtests (like piglit does). + After having compiled the tests, one can run the test-suite with: - The more comfortable way to run tests is with piglit. First grab piglit - from: + $ sudo make run-tests - git://anongit.freedesktop.org/piglit + As we have display tests, we need to be DRM master. As a result the + test suite can only be run if no other DRM client is active. + Similarly, some tests access debugfs, so we need to be root. - and build it (no need to install anything). Then we need to link up the - i-g-t sources with piglit + make run-tests create a $date-piglit-results.$n directory with the + results of the run. More specifically: + - $date-piglit-results.$n/main JSON file with the test results + - $date-piglit-results.$n/html/index.html HTML summary of the run - piglit-sources $ cd bin - piglit-sources/bin $ ln $i-g-t-sources igt -s + Where $date is the date formated with `date +%Y%m%d` and $n the nth run + of the day. - The tests in the i-g-t sources need to have been built already. Then we - can run the testcases with (as usual as root, no other drm clients - running): + PIGLIT_FLAGS can be used to give options to the underlying piglit + runner. For instance, to exclude test matching '^kms_': - piglit-sources # ./piglit-run.py tests/igt.tests results-file + $ sudo make run-tests PIGLIT_FLAGS=-x ^kms_ - The testlist is built at runtime, so no need to update anything in - piglit when adding new tests. See + For the list of piglit options, run: - piglit-sources $ ./piglit-run.py -h + $ ./piglit/piglit-run.py -h - for some useful options. + Another useful feature is to be able to resume an interrupted run. To + do that, make run-tests needs to know which run we are talking about: - Piglit only runs a default set of tests and is useful for regression - testing. Other tests not run are: - - tests that might hang the gpu, see HANG in Makefile.am + $ sudo make run-tests RESUME=$date-piglit-results.$n + + or, more succinctly: + + $ sudo make run-tests R=$date-piglit-results.$n + + It's possible to combine PIGLIT_FLAGS and RESUME. This is useful to + resume runs where a specific test deterministically hang the machine: + + $ sudo make run-tests PIGLIT_FLAGS=-x drv_module_reload R=$date-piglit-results.$n + + make run-tests only runs a default set of tests and is useful for + regression testing. Other tests not run are: + - tests that might hang the gpu, see HANG in tests/Makefile.sources - gem_stress, a stress test suite. Look at the source for all the various options. - testdisplay is only run in the default mode. testdisplay has tons of -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 22/23] lib: Change SLOW_QUICK() to use igt_run_quick()
IGT_QUICK=1 is now triggering the quick version of the tests. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- lib/drmtest.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/drmtest.h b/lib/drmtest.h index c93fe6b..3a07329 100644 --- a/lib/drmtest.h +++ b/lib/drmtest.h @@ -303,7 +303,7 @@ static inline void gem_require_ring(int fd, int ring_id) /* helpers to automatically reduce test runtime */ bool igt_run_in_simulation(void); bool igt_run_quick(void); -#define SLOW_QUICK(slow,quick) (igt_run_in_simulation() ? (quick) : (slow)) +#define SLOW_QUICK(slow,quick) (igt_run_quick() ? (quick) : (slow)) /** * igt_skip_on_simulation - skip tests when INTEL_SIMULATION env war is set * -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/23] framework: Dump the result of 'uname -a' in the report
Sent to the piglit ml:
http://lists.freedesktop.org/archives/piglit/2013-November/008465.html
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
piglit/framework/core.py | 3 +++
piglit/framework/summary.py| 1 +
piglit/templates/testrun_info.mako | 6 ++
3 files changed, 10 insertions(+)
diff --git a/piglit/framework/core.py b/piglit/framework/core.py
index e0fe46c..e0b49f8 100644
--- a/piglit/framework/core.py
+++ b/piglit/framework/core.py
@@ -293,11 +293,13 @@ class TestrunResult:
self.serialized_keys = ['options',
'name',
'tests',
+'uname',
'wglinfo',
'glxinfo',
'lspci',
'time_elapsed']
self.name = None
+self.uname = None
self.glxinfo = None
self.lspci = None
self.time_elapsed = None
@@ -432,6 +434,7 @@ class Environment:
else:
result['glxinfo'] = self.run('glxinfo')
if system == 'Linux':
+result['uname'] = self.run(['uname', '-a'])
result['lspci'] = self.run('lspci')
return result
diff --git a/piglit/framework/summary.py b/piglit/framework/summary.py
index a85353a..13596ea 100644
--- a/piglit/framework/summary.py
+++ b/piglit/framework/summary.py
@@ -458,6 +458,7 @@ class Summary:
out.write(testindex.render(name=each.name,
time=humanize_time(each.time_elapsed),
options=each.options,
+ uname=each.uname,
glxinfo=each.glxinfo,
lspci=each.lspci))
diff --git a/piglit/templates/testrun_info.mako
b/piglit/templates/testrun_info.mako
index e6e00b3..6ff1f44 100644
--- a/piglit/templates/testrun_info.mako
+++ b/piglit/templates/testrun_info.mako
@@ -30,6 +30,12 @@
td${options}/td
/tr
tr
+tduname -a/td
+td
+ pre${uname}/pre
+/td
+ /tr
+ tr
tdlspci/td
td
pre${lspci}/pre
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/23] piglit: Add a hint that there's an HTML summary
And also add the possibility for someone to copy/paste the index.html
path to view the HTML summary for use with, say, xdg-open.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile.am b/Makefile.am
index 4eace31..bd86a29 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -72,6 +72,7 @@ run-tests:
fi; \
$(PIGLIT) $${PIGLIT_FLAGS} $(IGT_TESTS) $$output \
$(PIGLIT_HTML) --overwrite $$output/html $$output/main \
+ echo HTML summary is at $$output/html/index.html \
$(PIGLIT_SUMMARY) $$output/main
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/23] piglit: Run our test suite with --no-concurrency
Tests tend to assume they are the only thing running, some need DRM master, some fill the memory. All in all, they are some correctness issues if we run tests concurrently. Acked-by: Ben Widawsky b...@bwidawsk.net Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 5742b82..f280879 100644 --- a/Makefile.am +++ b/Makefile.am @@ -50,7 +50,7 @@ dist-hook: ChangeLog INSTALL # # Useful shortcuts to run tests # -PIGLIT := $(srcdir)/piglit/piglit-run.py +PIGLIT := $(srcdir)/piglit/piglit-run.py --no-concurrency PIGLIT_SUMMARY := $(srcdir)/piglit/piglit-summary.py -s PIGLIT_HTML := $(srcdir)/piglit/piglit-summary-html.py IGT_TESTS := $(abs_srcdir)/piglit/tests/igt.tests -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/23] piglit: Add the option to inject piglit arguments
This is useful in extreme cases (for instance, to exclude
drv_module_reload if known to fail).
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
Makefile.am | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile.am b/Makefile.am
index 8611929..471dd3d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -61,6 +61,7 @@ run-tests:
@source $(srcdir)/scripts/build-piglit.sh \
output=$$(igt_result_directory) \
$(PIGLIT) $(IGT_TESTS) $$output \
+ $(PIGLIT) $${PIGLIT_FLAGS} $(IGT_TESTS) $$output \
$(PIGLIT_HTML) $$output/html $$output/main \
$(PIGLIT_SUMMARY) $$output/main
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/23] piglit: Add a 'run-tests' Makefile target
Let's start to craft porcelain targets to run the test suite. First
stop, run the piglit tests enumerated by igt.tests.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
Makefile.am | 20
scripts/Makefile.am | 2 +-
scripts/build-piglit.sh | 20
3 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644 scripts/build-piglit.sh
diff --git a/Makefile.am b/Makefile.am
index d7a479c..8611929 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -46,3 +46,23 @@ ChangeLog:
$(CHANGELOG_CMD)
dist-hook: ChangeLog INSTALL
+
+#
+# Useful shortcuts to run tests
+#
+PIGLIT := $(srcdir)/piglit/piglit-run.py
+PIGLIT_SUMMARY := $(srcdir)/piglit/piglit-summary.py -s
+PIGLIT_HTML := $(srcdir)/piglit/piglit-summary-html.py
+IGT_TESTS := $(abs_srcdir)/piglit/tests/igt.tests
+TEST_TARGETS := #
+
+TEST_TARGETS += run-test
+run-tests:
+ @source $(srcdir)/scripts/build-piglit.sh \
+ output=$$(igt_result_directory) \
+ $(PIGLIT) $(IGT_TESTS) $$output \
+ $(PIGLIT_HTML) $$output/html $$output/main \
+ $(PIGLIT_SUMMARY) $$output/main
+
+
+.PHONY: $(TEST_TARGETS)
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index baf3612..1cabd3f 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -1,3 +1,3 @@
-dist_noinst_SCRIPTS = who.sh
+dist_noinst_SCRIPTS = who.sh build-piglit.sh
noinst_PYTHON = throttle.py
diff --git a/scripts/build-piglit.sh b/scripts/build-piglit.sh
new file mode 100644
index 000..832b5bf
--- /dev/null
+++ b/scripts/build-piglit.sh
@@ -0,0 +1,20 @@
+#!/bin/bash
+# This script is sourced by Makefiles to provide various utility functions
+
+function igt_result_directory()
+{
+ suite=$1
+ [ -z $suite ] suite=results
+
+ date=`date +%Y%m%d`
+ base=$date-piglit-$suite
+
+ n=1
+ dir=$base.$n
+ while [ -e $dir ]; do
+ let n+=1
+ dir=$base.$n
+ done
+
+ echo $dir
+}
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/23] lib: Introduce igt_run_quick()
Turns out that we'd like to be able a quick version of the tests on
real hardware as well. So in simulation and quick are two different
concepts.
Note that in simulation implies quick, so igt_run_quick() tests if
we are running on simulation before looking at the IGT_QUICK env
variable.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
lib/drmtest.c | 15 +++
lib/drmtest.h | 3 ++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 15ed847..5760c87 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -1278,6 +1278,21 @@ bool igt_run_in_simulation(void)
return simulation;
}
+bool igt_run_quick(void)
+{
+ static int quick = -1;
+
+ if (quick == -1) {
+ if (igt_run_in_simulation())
+ quick = true;
+ else
+ quick = env_set(IGT_QUICK, false);
+ }
+
+ return quick;
+}
+
+
/**
* igt_skip_on_simulation - skip tests when INTEL_SIMULATION env war is set
*
diff --git a/lib/drmtest.h b/lib/drmtest.h
index 5295a7b..c93fe6b 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -300,8 +300,9 @@ static inline void gem_require_ring(int fd, int ring_id)
}
}
-/* helpers to automatically reduce test runtime in simulation */
+/* helpers to automatically reduce test runtime */
bool igt_run_in_simulation(void);
+bool igt_run_quick(void);
#define SLOW_QUICK(slow,quick) (igt_run_in_simulation() ? (quick) : (slow))
/**
* igt_skip_on_simulation - skip tests when INTEL_SIMULATION env war is set
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/23] piglit: Merge filters from previous invocations when resuming
This commit has been posted to the piglit ml: http://lists.freedesktop.org/archives/piglit/2013-November/008452.html Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- piglit/piglit-run.py | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/piglit/piglit-run.py b/piglit/piglit-run.py index 1d63cd4..d11d409 100755 --- a/piglit/piglit-run.py +++ b/piglit/piglit-run.py @@ -99,10 +99,15 @@ def main(): old_results = core.load_results(resultsDir) profileFilename = old_results.options['profile'] -# Changing the args to the old args allows us to set them -# all in one places down the way -args.exclude_tests = old_results.options['exclude_filter'] -args.include_tests = old_results.options['filter'] +# Append the test filters that were given in previous runs to the ones +# given in the resume invocation +for f in old_results.options['exclude_filter']: +if f not in args.exclude_tests: +args.exclude_tests.append(f) + +for f in old_results.options['filter']: +if f not in args.include_tests: +args.include_tests.append(f) # Otherwise parse additional settings from the command line else: -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/23] drm_lib.sh: Tune the DRM master message a bit
check_drm_clients can be used to make sure there's no master running. Tune a bit the error message as this is really what we want to test. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- tests/drm_lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh index 97f6f92..92b379f 100755 --- a/tests/drm_lib.sh +++ b/tests/drm_lib.sh @@ -31,7 +31,7 @@ fi # read everything we can if [ `cat $i915_dfs_path/clients | wc -l` -gt 2 ] ; then [ -n $DRM_LIB_ALLOW_NO_MASTER ] || \ - die ERROR: other drm clients running + die ERROR: a drm master is already running fi i915_sfs_path= -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/23] piglit: Support R= as RESUME= for the lazies
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
Makefile.am | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index bd86a29..5086406 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -58,13 +58,14 @@ TEST_TARGETS := #
TEST_TARGETS += run-test
run-tests:
- @if [ -n $(RESUME) ]; then \
- [ ! -f $(RESUME)/main ] { \
- echo $(RESUME) is not a valid piglit project; \
+ @[ -z $(RESUME) -a -n $(R) ] RESUME=$(R); \
+ if [ -n $$RESUME ]; then \
+ [ ! -f $$RESUME/main ] { \
+ echo $$RESUME is not a valid piglit project; \
exit 1; \
}; \
- output=$(RESUME); \
- echo Resuming $(RESUME)...; \
+ output=$$RESUME; \
+ echo Resuming $$RESUME...; \
PIGLIT_FLAGS=--resume $$PIGLIT_FLAGS; \
else \
source $(srcdir)/scripts/build-piglit.sh \
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 17/23] piglit: Make sure there's no DRM master before launching the tests
Also, use between statements so we stop the chain once something
fails.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
Makefile.am | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index 5086406..e790efe 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -59,6 +59,7 @@ TEST_TARGETS := #
TEST_TARGETS += run-test
run-tests:
@[ -z $(RESUME) -a -n $(R) ] RESUME=$(R); \
+ $(srcdir)/tests/check_drm_clients \
if [ -n $$RESUME ]; then \
[ ! -f $$RESUME/main ] { \
echo $$RESUME is not a valid piglit project; \
@@ -70,7 +71,7 @@ run-tests:
else \
source $(srcdir)/scripts/build-piglit.sh \
output=$$(igt_result_directory); \
- fi; \
+ fi \
$(PIGLIT) $${PIGLIT_FLAGS} $(IGT_TESTS) $$output \
$(PIGLIT_HTML) --overwrite $$output/html $$output/main \
echo HTML summary is at $$output/html/index.html \
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/23] piglit: Make sure we are running the tests as root
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
Makefile.am| 1 +
tests/Makefile.sources | 1 +
tests/check_root | 5 +
3 files changed, 7 insertions(+)
create mode 100755 tests/check_root
diff --git a/Makefile.am b/Makefile.am
index e790efe..7988d01 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -59,6 +59,7 @@ TEST_TARGETS := #
TEST_TARGETS += run-test
run-tests:
@[ -z $(RESUME) -a -n $(R) ] RESUME=$(R); \
+ $(srcdir)/tests/check_root \
$(srcdir)/tests/check_drm_clients \
if [ -n $$RESUME ]; then \
[ ! -f $$RESUME/main ] { \
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index a02b93d..eb2b511 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -187,6 +187,7 @@ HANG = \
scripts = \
check_drm_clients \
+ check_root \
ddx_intel_after_fbdev \
debugfs_wedged \
drm_lib.sh \
diff --git a/tests/check_root b/tests/check_root
new file mode 100755
index 000..5d49f0d
--- /dev/null
+++ b/tests/check_root
@@ -0,0 +1,5 @@
+#!/bin/sh
+[ `id -u` = 0 ] || {
+ echo Error: Not running as root
+ exit 1
+}
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/23] piglit: Always write the HTML test results
Even if a previous run has already done it. Useful when resuming an
already done test (which in turns is useful to load/write the json file
to apply any piglit change).
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index 0f9af6c..4eace31 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -71,7 +71,7 @@ run-tests:
output=$$(igt_result_directory); \
fi; \
$(PIGLIT) $${PIGLIT_FLAGS} $(IGT_TESTS) $$output \
- $(PIGLIT_HTML) $$output/html $$output/main \
+ $(PIGLIT_HTML) --overwrite $$output/html $$output/main \
$(PIGLIT_SUMMARY) $$output/main
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/23] piglit: Fix resuming of previous runs
When resuming and loading the partial JSON file from disk, the 'status' property is replaced by status.Status objects. When serializing back those objects, JSONEncoder is unhappy because it doesn't know how to serialize status.Status objects and gives up with exceptions like: TypeError: skip is not JSON serializable We can write a small subclass of JSONEncoder that knows about Status objects and use it to do the initial write back of the partial JSON file. This commit has been posted on the piglit ml: http://lists.freedesktop.org/archives/piglit/2013-November/008447.html Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- piglit/framework/core.py | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/piglit/framework/core.py b/piglit/framework/core.py index e7767c2..e0fe46c 100644 --- a/piglit/framework/core.py +++ b/piglit/framework/core.py @@ -58,6 +58,11 @@ __all__ = ['Environment', 'Test', 'testBinDir'] +class PiglitJSONEncoder(json.JSONEncoder): +def default(self, o): +if isinstance(o, status.Status): +return str(o) +return json.JSONEncoder.default(self, o) class JSONWriter: ''' @@ -108,7 +113,7 @@ class JSONWriter: self.file = file self.__indent_level = 0 self.__inhibit_next_indent = False -self.__encoder = json.JSONEncoder(indent=self.INDENT) +self.__encoder = PiglitJSONEncoder(indent=self.INDENT) # self.__is_collection_empty # -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/23] piglit: Generate a Makefile.am from the sync script
When syncing the piglit runner, also generate the Makefile.am to include the runner in a dist'ed tarball Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- Makefile.am | 2 +- configure.ac| 1 + piglit/Makefile.am | 29 + piglit/sync-from-piglit | 20 4 files changed, 51 insertions(+), 1 deletion(-) create mode 100644 piglit/Makefile.am diff --git a/Makefile.am b/Makefile.am index f280879..0f9af6c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -32,7 +32,7 @@ SUBDIRS += debugger endif if BUILD_TESTS -SUBDIRS += tests +SUBDIRS += piglit tests endif MAINTAINERCLEANFILES = ChangeLog INSTALL diff --git a/configure.ac b/configure.ac index 0403529..18ab05d 100644 --- a/configure.ac +++ b/configure.ac @@ -193,6 +193,7 @@ AC_CONFIG_FILES([ lib/Makefile man/Makefile scripts/Makefile +piglit/Makefile tests/Makefile tools/Makefile tools/quick_dump/Makefile diff --git a/piglit/Makefile.am b/piglit/Makefile.am new file mode 100644 index 000..0362786 --- /dev/null +++ b/piglit/Makefile.am @@ -0,0 +1,29 @@ +# This file is generated, do not edit +EXTRA_DIST = \ + tests/igt.tests \ + templates/testrun_info.mako \ + templates/test_result.mako \ + templates/index.mako \ + templates/index.css \ + templates/result.css \ + templates/empty_status.mako \ + piglit-merge-results.py \ + piglit-summary.py \ + sync-from-piglit \ + piglit-run.py \ + framework/status.py \ + framework/log.py \ + framework/patterns.py \ + framework/junit.py \ + framework/threads.py \ + framework/gleantest.py \ + framework/__init__.py \ + framework/exectest.py \ + framework/summary.py \ + framework/core.py \ + framework/threadpool.py \ + piglit-summary-junit.py \ + piglit-framework-tests.py \ + piglit-print-commands.py \ + piglit-summary-html.py \ + $(NULL) diff --git a/piglit/sync-from-piglit b/piglit/sync-from-piglit index 20a95ff..b3b7bd8 100755 --- a/piglit/sync-from-piglit +++ b/piglit/sync-from-piglit @@ -21,4 +21,24 @@ rsync -rtv --exclude-from $EXCLUDE_FILE \ $PIGLIT_DIR/piglit-*.py \ $BASE_DIR +files=$(cd $BASE_DIR find . \ + -not -type d\ + -not -name *.pyc \ + -not -name *.sw? \ + -not -name sync-exclude \ + -not -name Makefile* |\ + grep -v -e ^.$ | \ + sed -e 's#^\./##') +for f in $files; do + FILE_LIST=\t$f \\ +$FILE_LIST +done + +cat EOF $BASE_DIR/Makefile.am +# This file is generated, do not edit +EXTRA_DIST = \\ +EOF +echo -n -e $FILE_LIST $BASE_DIR/Makefile.am +echo -e \t\$(NULL) $BASE_DIR/Makefile.am + rm -f $EXCLUDE_FILE -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/23] framework: Humanize time values in the HTML report
It's a bit hard to parse raw seconds, so make those time values easier
to read while trying to preserve roughly enough relevant precision to be
useful.
It gives strings like:
22.4ms
7.798s
42.3s
7min 25s
...
v2: Remove support for days, weeks, months and years, surely no test
should be that long! (Daniel Vetter)
Display 1 decimal if the duration is 60s (Daniel Vetter)
Sent to the piglit ml:
http://lists.freedesktop.org/archives/piglit/2013-November/008464.html
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
piglit/framework/summary.py | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/piglit/framework/summary.py b/piglit/framework/summary.py
index 8fbe2a8..a85353a 100644
--- a/piglit/framework/summary.py
+++ b/piglit/framework/summary.py
@@ -38,6 +38,42 @@ __all__ = [
]
+INTERVALS = (1, 60, 3600)
+NAMES = ('s', 'min', 'hr')
+
+# Gives a human readable elapsed time
+# @amount is a string with a number of seconds
+def humanize_time(amount):
+result = []
+
+if amount == 'None':
+return 'None'
+
+amount_f = float(amount)
+if (amount_f 1):
+amount_ms = amount_f * 1000
+if amount_ms 1:
+return 1ms
+return %.1fms % amount_ms
+
+# if 10s, consider ms are important
+if amount_f 10:
+return %.03fs % amount_f
+
+# still display 1 decimal when 60s
+if amount_f 60:
+return %.01fs % amount_f
+
+amount = int(amount_f)
+
+for i in range(len(NAMES) - 1, -1, -1):
+ a = amount / INTERVALS[i]
+ if a 0:
+ result.append(%d%s % (a, NAMES[i]))
+ amount -= a * INTERVALS[i]
+
+return .join(result)
+
class HTMLIndex(list):
Builds HTML output to be passed to the index mako template, which will be
@@ -420,7 +456,7 @@ class Summary:
with open(path.join(destination, each.name, index.html), 'w') as
out:
out.write(testindex.render(name=each.name,
- time=each.time_elapsed,
+
time=humanize_time(each.time_elapsed),
options=each.options,
glxinfo=each.glxinfo,
lspci=each.lspci))
@@ -447,7 +483,7 @@ class Summary:
# disapear at somepoint
env=value.get('environment', None),
returncode=value.get('returncode', 'None'),
-time=value.get('time', 'None'),
+time=humanize_time(value.get('time', 'None')),
info=value.get('info', 'None'),
traceback=value.get('traceback', 'None'),
command=value.get('command', 'None'),
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Workaround for flicker with panning on the i830 - found a way for tiled displays
Hi Daniel, Gosh, should have read the code more closely. We have a totally botched wm setup on i830M - the watermark code for the 2nd pipe is just not there! Well, nice try, but no cigar. (-: That's actually much worse than before. The display is now unstable on *both* the internal and external display, and inspecting the FW_BLC register, it is completely off. The current code leaves it at 0x1050101, but it should be at least 0x1060106, that is, the watermark needs to be higher, not lower. I still don't understand why a higher latency causes a lower watermark, but maybe things work different than in my mental model. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revised i830 flicker workaround
Dear Daniel, and intel experts,
please find a revised patch concerning the i830 panning flicker attached.
The code should be much cleaner now, though it currently only addresses
the linear (and not the tiled) mode.
Thanks,
Thomas
From fbb59580f1d85efeb9e2d155ce46791cb8b23c2d Mon Sep 17 00:00:00 2001
From: Thomas Richter t...@math.tu-berlin.de
Date: Fri, 15 Nov 2013 11:53:55 +0100
Subject: [PATCH 11/11] Updated i830 patch to avoid pipe-A underruns.
This patch addresses a hardware issue on i830 chipsets that cause pipe A
underruns on screens where the base address is misaligned. This typically
happens when panning. The hardware issue causes at least an anoying
flicker at certain screen positions, but in worst case crashes and system
hangs when video overlays are active.
While details are still unknown, this workaround reloads the display base
address to an aligned position, causing the FIFO to fill, then adjusts the
base address to its final position.
The patch currently only works in linear framebuffer mode, tiled modes
are harder to address.
v1: First attempt to address the issue by an inline code.
v2: pulled out the inline code to a separate function
v3: cosmetical cleanups, removal of debug code.
Signed-off-by: Thomas Richter t...@math.tu-berlin.de
---
drivers/gpu/drm/i915/intel_display.c | 59 +-
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 971f6b9..566fe4d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2002,6 +2002,60 @@ unsigned long intel_gen4_compute_page_offset(int *x, int *y,
}
}
+/*
+ * Update the linear frame pointer for i830 based devices. Due to some
+ * unknown hardware feature, updating the frame pointer may cause
+ * the unified FIFO of these chips run dry, then causing a flicker
+ * and a potential shutdown of the video overlay, or worse.
+ * thor, 14.11.2013
+ */
+static void i830_update_plane_offset(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ unsigned long linear_offset)
+{
+ struct drm_i915_gem_object *obj;
+ struct intel_framebuffer *intel_fb;
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long planeadr, oldadr;
+ int plane = intel_crtc-plane;
+ u32 reg = DSPCNTR(plane);
+
+ intel_fb = to_intel_framebuffer(fb);
+ obj = intel_fb-obj;
+
+ planeadr = i915_gem_obj_ggtt_offset(obj) + linear_offset;
+ /* I830 panning flicker work around.
+ * Only for non-LVDS output, only for i830.
+ * Tiling mode is still not supported.
+ */
+ if (obj-tiling_mode != I915_TILING_NONE) {
+ /*
+ * a suitable workaround for tiling is not
+ * yet available... TBD.
+ */
+ } else {
+ switch (fb-bits_per_pixel) {
+ case 32:
+ case 16:
+ oldadr = I915_READ(DSPADDR(plane));
+ if (((oldadr ^ planeadr) 0x40)
+ (planeadr 0xc0) == 0xc0) {
+I915_WRITE(DSPADDR(plane),
+ planeadr (~(0x80)));
+POSTING_READ(reg);
+intel_wait_for_vblank(dev, intel_crtc-pipe);
+ }
+ break;
+ case 8:
+ /* workaround still to be done */
+ break;
+ }
+ }
+ I915_WRITE(DSPADDR(plane), planeadr);
+}
+
static int i9xx_update_plane(struct drm_crtc *crtc, struct drm_framebuffer *fb,
int x, int y)
{
@@ -2094,7 +2148,10 @@ static int i9xx_update_plane(struct drm_crtc *crtc, struct drm_framebuffer *fb,
I915_MODIFY_DISPBASE(DSPSURF(plane),
i915_gem_obj_ggtt_offset(obj) + intel_crtc-dspaddr_offset);
I915_WRITE(DSPTILEOFF(plane), (y 16) | x);
- I915_WRITE(DSPLINOFF(plane), linear_offset);
+ I915_WRITE(DSPLINOFF(plane), linear_offset);
+ } else if (IS_I830(dev)
+ !intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
+ i830_update_plane_offset(crtc, fb, linear_offset);
} else
I915_WRITE(DSPADDR(plane), i915_gem_obj_ggtt_offset(obj) + linear_offset);
POSTING_READ(reg);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/23] piglit: Run our test suite with --no-concurrency
On Fri, Nov 15, 2013 at 04:33:27PM +, Damien Lespiau wrote: Tests tend to assume they are the only thing running, some need DRM master, some fill the memory. All in all, they are some correctness issues if we run tests concurrently. Acked-by: Ben Widawsky b...@bwidawsk.net Signed-off-by: Damien Lespiau damien.lesp...@intel.com Concurrency is a per-test opt-in thing in piglit. So this is cargo-cult and worse will prevent us to run a subset of tests to run in parallel (e.g. once we have a naming scheme for abi stuff). -Daniel --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 5742b82..f280879 100644 --- a/Makefile.am +++ b/Makefile.am @@ -50,7 +50,7 @@ dist-hook: ChangeLog INSTALL # # Useful shortcuts to run tests # -PIGLIT := $(srcdir)/piglit/piglit-run.py +PIGLIT := $(srcdir)/piglit/piglit-run.py --no-concurrency PIGLIT_SUMMARY := $(srcdir)/piglit/piglit-summary.py -s PIGLIT_HTML := $(srcdir)/piglit/piglit-summary-html.py IGT_TESTS := $(abs_srcdir)/piglit/tests/igt.tests -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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 16/23] drm_lib.sh: Tune the DRM master message a bit
On Fri, Nov 15, 2013 at 04:33:33PM +, Damien Lespiau wrote: check_drm_clients can be used to make sure there's no master running. Tune a bit the error message as this is really what we want to test. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- tests/drm_lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh index 97f6f92..92b379f 100755 --- a/tests/drm_lib.sh +++ b/tests/drm_lib.sh @@ -31,7 +31,7 @@ fi # read everything we can if [ `cat $i915_dfs_path/clients | wc -l` -gt 2 ] ; then [ -n $DRM_LIB_ALLOW_NO_MASTER ] || \ - die ERROR: other drm clients running + die ERROR: a drm master is already running Imo the current line is clear enough and we do actually check for any drm client, not just master ... But I don't really care. -Daniel fi i915_sfs_path= -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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 19/23] piglit: Update the README file with the new way of running tests
On Fri, Nov 15, 2013 at 04:33:36PM +, Damien Lespiau wrote: Signed-off-by: Damien Lespiau damien.lesp...@intel.com Hm, I'd keep the references to the real piglit somewhere, since our copy here is just for convenience. Development should happen upstream. -Daniel --- README | 54 -- 1 file changed, 32 insertions(+), 22 deletions(-) diff --git a/README b/README index 246e24c..021888f 100644 --- a/README +++ b/README @@ -24,38 +24,48 @@ tests/ changes. Hopefully this can cover the relevant cases we need to worry about, including backwards compatibility. - Note: The old automake based testrunner had to be scraped due to - upstream changes which broke dynamic creation of the test list. Of - course it is still possible to directly run tests, even when not always - limiting tests to specific subtests (like piglit does). + After having compiled the tests, one can run the test-suite with: - The more comfortable way to run tests is with piglit. First grab piglit - from: + $ sudo make run-tests - git://anongit.freedesktop.org/piglit + As we have display tests, we need to be DRM master. As a result the + test suite can only be run if no other DRM client is active. + Similarly, some tests access debugfs, so we need to be root. - and build it (no need to install anything). Then we need to link up the - i-g-t sources with piglit + make run-tests create a $date-piglit-results.$n directory with the + results of the run. More specifically: + - $date-piglit-results.$n/main JSON file with the test results + - $date-piglit-results.$n/html/index.html HTML summary of the run - piglit-sources $ cd bin - piglit-sources/bin $ ln $i-g-t-sources igt -s + Where $date is the date formated with `date +%Y%m%d` and $n the nth run + of the day. - The tests in the i-g-t sources need to have been built already. Then we - can run the testcases with (as usual as root, no other drm clients - running): + PIGLIT_FLAGS can be used to give options to the underlying piglit + runner. For instance, to exclude test matching '^kms_': - piglit-sources # ./piglit-run.py tests/igt.tests results-file + $ sudo make run-tests PIGLIT_FLAGS=-x ^kms_ - The testlist is built at runtime, so no need to update anything in - piglit when adding new tests. See + For the list of piglit options, run: - piglit-sources $ ./piglit-run.py -h + $ ./piglit/piglit-run.py -h - for some useful options. + Another useful feature is to be able to resume an interrupted run. To + do that, make run-tests needs to know which run we are talking about: - Piglit only runs a default set of tests and is useful for regression - testing. Other tests not run are: - - tests that might hang the gpu, see HANG in Makefile.am + $ sudo make run-tests RESUME=$date-piglit-results.$n + + or, more succinctly: + + $ sudo make run-tests R=$date-piglit-results.$n + + It's possible to combine PIGLIT_FLAGS and RESUME. This is useful to + resume runs where a specific test deterministically hang the machine: + + $ sudo make run-tests PIGLIT_FLAGS=-x drv_module_reload R=$date-piglit-results.$n + + make run-tests only runs a default set of tests and is useful for + regression testing. Other tests not run are: + - tests that might hang the gpu, see HANG in tests/Makefile.sources - gem_stress, a stress test suite. Look at the source for all the various options. - testdisplay is only run in the default mode. testdisplay has tons of -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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 10/23] piglit: Run our test suite with --no-concurrency
On Fri, Nov 15, 2013 at 06:08:27PM +0100, Daniel Vetter wrote: On Fri, Nov 15, 2013 at 04:33:27PM +, Damien Lespiau wrote: Tests tend to assume they are the only thing running, some need DRM master, some fill the memory. All in all, they are some correctness issues if we run tests concurrently. Acked-by: Ben Widawsky b...@bwidawsk.net Signed-off-by: Damien Lespiau damien.lesp...@intel.com Concurrency is a per-test opt-in thing in piglit. So this is cargo-cult and worse will prevent us to run a subset of tests to run in parallel (e.g. once we have a naming scheme for abi stuff). Right now, the concurrency runs have big problems. Running anything along drv_module_reload will fail to open the device (and as it fails quickly, a lot of tests will end up being skipped (instead of failing, which is another bug)). Hence using --no-concurrency for now. It's something we can maintain in tree though, and remove once we are more confident it has a reasonable chance to work. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/23] drm_lib.sh: Tune the DRM master message a bit
On Fri, Nov 15, 2013 at 06:13:48PM +0100, Daniel Vetter wrote: On Fri, Nov 15, 2013 at 04:33:33PM +, Damien Lespiau wrote: check_drm_clients can be used to make sure there's no master running. Tune a bit the error message as this is really what we want to test. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- tests/drm_lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh index 97f6f92..92b379f 100755 --- a/tests/drm_lib.sh +++ b/tests/drm_lib.sh @@ -31,7 +31,7 @@ fi # read everything we can if [ `cat $i915_dfs_path/clients | wc -l` -gt 2 ] ; then [ -n $DRM_LIB_ALLOW_NO_MASTER ] || \ - die ERROR: other drm clients running + die ERROR: a drm master is already running Imo the current line is clear enough and we do actually check for any drm client, not just master ... But I don't really care. Me neither, I'm fine with dropping the patch. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt] Making the test-suite easier to run
On Fri, Nov 15, 2013 at 04:33:17PM +, Damien Lespiau wrote: Another useful feature is to be able to resume an interrupted run. To do that, make run-tests needs to know which run we are talking about: There's a known bug with piglit here in that resuming doesn't conserve --no-concurrency from the initial work. Dylan Baker has fixed it and we can get the fix with the next piglit sync. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/23] piglit: Update the README file with the new way of running tests
On Fri, Nov 15, 2013 at 06:16:08PM +0100, Daniel Vetter wrote: On Fri, Nov 15, 2013 at 04:33:36PM +, Damien Lespiau wrote: Signed-off-by: Damien Lespiau damien.lesp...@intel.com Hm, I'd keep the references to the real piglit somewhere, since our copy here is just for convenience. Development should happen upstream. Right, I thought it goes without saying, but a note about this is definitly better. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt] Making the test-suite easier to run
On Fri, Nov 15, 2013 at 04:33:17PM +, Damien Lespiau wrote: The objective of this series is to make the test-suite easier to run by embedding a copy a piglit and providing porcelain on top of it in the form of a makefile target. Beside python, there's no external dependency to run the test suite after this series. The provided makefile target runs the full test suite. I'm still interested in providing, as a follow-up of this work, shorcuts for subsets of the testsuite that can be useful for developpers, subset what we would maintain in tree. For instance: - tests selected by topic: running gem_.* Vs kms_.* Vs pm_.* (or maybe when running, say, gt tests, exlude ^kms_.* ^pm_.* so we still still a lot of the other tests (core_, drm_, ...) - quick subtests (where we disable long running stress, race, ... tests) patches 21-23 are something a bit different, try to pave the way for quick runs (by really the first tiny step). I'm ok with doing the slow/quick thing if people like it.o On the real deal (i.e. patches 1-20) a few overall comments: - I think we need to make it very clear that piglit should still be developed upstream. So local changes shouldn't be allowed at all imo. Afaics that would only affect tests/igt.tests - can't we fix that by replicating the symlink, too? - The makefile target looks like a script. I think it'd be better to extract it as a real script. - I'm not too terribly sold on the convenience script. Imo it shouldn't be more than executable documentation, since I'm a bit afraid that we'll add neat features (like fancy resume with auto-blocking of crashing tests) to it that would better be done in upstream piglit to benefit everyone. But overall I agree that we need a local copy of piglit since apparently way too few people on our team us it to run igts. And running igts without piglit is just nuts. Cheers, Daniel The README has been updated and I copy/paste it here the documentation for what would be the new way to run tests: After having compiled the tests, one can run the test-suite with: $ sudo make run-tests make run-tests create a $date-piglit-results.$n directory with the results of the run. More specifically: - $date-piglit-results.$n/main JSON file with the test results - $date-piglit-results.$n/html/index.html HTML summary of the run Where $date is the date formated with `date +%Y%m%d` and $n the nth run of the day. PIGLIT_FLAGS can be used to give options to the underlying piglit runner. For instance, to exclude test matching '^kms_': $ sudo make run-tests PIGLIT_FLAGS=-x ^kms_ For the list of piglit options, run: $ ./piglit/piglit-run.py -h Another useful feature is to be able to resume an interrupted run. To do that, make run-tests needs to know which run we are talking about: $ sudo make run-tests RESUME=$date-piglit-results.$n or, more succinctly: $ sudo make run-tests R=$date-piglit-results.$n It's possible to combine PIGLIT_FLAGS and RESUME. This is useful to resume runs where a specific test deterministically hang the machine: $ sudo make run-tests PIGLIT_FLAGS=-x drv_module_reload R=$date-piglit-results.$n HTH, -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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
[Intel-gfx] [PATCH 2/2] drm/i915/vlv: use parallel context restore when coming out of RC6
Setting this bit restores all ring contexts in parallel rather than serially. Matches current BWG recommendations. Tested-by: Meng, Mengmeng mengmeng.m...@intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 849e595..40b1136 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4891,6 +4891,7 @@ #define GEN6_RC_CTL_RC6_ENABLE (118) #define GEN6_RC_CTL_RC1e_ENABLE (120) #define GEN6_RC_CTL_RC7_ENABLE (122) +#define VLV_RC_CTL_CTX_RST_PARALLEL (124) #define GEN7_RC_CTL_TO_MODE (128) #define GEN6_RC_CTL_EI_MODE(x) ((x)27) #define GEN6_RC_CTL_HW_ENABLE(131) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 5d3912a..6a21d11 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4110,7 +4110,7 @@ static void valleyview_enable_rps(struct drm_device *dev) VLV_MEDIA_RC6_COUNT_EN | VLV_RENDER_RC6_COUNT_EN)); if (intel_enable_rc6(dev) INTEL_RC6_ENABLE) - rc6_mode = GEN7_RC_CTL_TO_MODE; + rc6_mode = GEN7_RC_CTL_TO_MODE | VLV_RC_CTL_CTX_RST_PARALLEL; intel_print_rc6_info(dev, rc6_mode); -- 1.8.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] intel: Add support for GPU reset status query ioctl
From: Ian Romanick ian.d.roman...@intel.com
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
This ioctl is in the drm-intel-next tree as b635991.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
v4: Import the actual changes from the kernel i915_drm.h. Only comments
on some fields of drm_i915_reset_stats differed. There are still some
deltas between the kernel i915_drm.h and the one in libdrm, but those
can be resolved in other patches.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org [v3]
Cc: Mika Kuoppala mika.kuopp...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
include/drm/i915_drm.h | 19 +++
intel/intel_bufmgr.h | 5 +
intel/intel_bufmgr_gem.c | 34 ++
3 files changed, 58 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index aa983f3..c1914d6 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -198,6 +198,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_SET_CACHEING 0x2f
#define DRM_I915_GEM_GET_CACHEING 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 DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READDRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
+#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -943,4 +945,21 @@ struct drm_i915_reg_read {
__u64 offset;
__u64 val; /* Return value */
};
+
+struct drm_i915_reset_stats {
+ __u32 ctx_id;
+ __u32 flags;
+
+ /* All resets since boot/module reload, for all contexts */
+ __u32 reset_count;
+
+ /* Number of batches lost when active in GPU, for this context */
+ __u32 batch_active;
+
+ /* Number of batches lost pending for execution, for this context */
+ __u32 batch_pending;
+
+ __u32 pad;
+};
+
#endif /* _I915_DRM_H_ */
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 7b28a70..34a5750 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -249,6 +249,11 @@ int drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
uint32_t offset,
uint64_t *result);
+int drm_intel_get_reset_stats(drm_intel_context *ctx,
+ uint32_t *reset_count,
+ uint32_t *active,
+ uint32_t *pending);
+
/** @{ Compatibility defines to keep old code building despite the symbol
rename
* from dri_* to drm_intel_*
*/
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index dbadc52..0b9252e 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3029,6 +3029,40 @@ drm_intel_gem_context_get_hw_context_id(const
drm_intel_context *ctx)
}
int
+drm_intel_get_reset_stats(drm_intel_context *ctx,
+ uint32_t *reset_count,
+ uint32_t *active,
+ uint32_t *pending)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem;
+ struct drm_i915_reset_stats stats;
+ int ret;
+
+ if (ctx == NULL)
+ return -EINVAL;
+
+ VG_CLEAR(stats);
+
+ bufmgr_gem = (drm_intel_bufmgr_gem *)ctx-bufmgr;
+ stats.ctx_id = ctx-ctx_id;
+ ret = drmIoctl(bufmgr_gem-fd,
+ DRM_IOCTL_I915_GET_RESET_STATS,
+ stats);
+ if (ret == 0) {
+ if (reset_count != NULL)
+ *reset_count = stats.reset_count;
+
+ if (active != NULL)
+ *active = stats.batch_active;
+
+ if (pending != NULL)
+ *pending = stats.batch_pending;
+ }
+
+ return ret;
+}
+
+int
drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
uint32_t offset,
uint64_t *result)
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] More questions and patches for 835GM/ns2501 DVO
On 15.11.2013 18:33, Daniel Vetter wrote: To clarify: Do you need this patch to make the single-pipe mode work reliably? It's a bit unclear in your answer ... To clarify my clarification question: Do you need the above quoted patch to make the cursor work better on your system? Well, at least it avoided one kernel warning. Or rather, I haven't seen it since. But otherwise, the cursor works fine. I don't have any problems with the cursor whatsoever, it always appears. This is not about a WARN or the flicker or dual pipe (last time I've asked you kinda went on a tangent). I'm asking again since this patch for the cursor code is currently blocked from merging because I couldn't get a clear this is needed, yes from you. It's hard to say whether it is needed, unfortunately. The kernel warning is not so easy to provoke, and there is no clear way to reproduce it. All I can say is that I haven't seen it since, and the patch has surely not made anything worse, so I would say go for it and include it. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Add support for GPU reset status query ioctl
On Fri, Nov 15, 2013 at 10:41:57AM -0800, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
I would have just used the drmIoctl interface directly in Mesa, but the
ioctl needs some data from the drm_intel_context that is not exposed
outside libdrm.
This ioctl is in the drm-intel-next tree as b635991.
v2: Update based on Mika's kernel work.
v3: Fix compile failures from last-minute typos. Sigh.
v4: Import the actual changes from the kernel i915_drm.h. Only comments
on some fields of drm_i915_reset_stats differed. There are still some
deltas between the kernel i915_drm.h and the one in libdrm, but those
can be resolved in other patches.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reviewed-by: Kenneth Graunke kenn...@whitecape.org [v3]
Cc: Mika Kuoppala mika.kuopp...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Looks good to me.
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
---
include/drm/i915_drm.h | 19 +++
intel/intel_bufmgr.h | 5 +
intel/intel_bufmgr_gem.c | 34 ++
3 files changed, 58 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index aa983f3..c1914d6 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -198,6 +198,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_SET_CACHEING0x2f
#define DRM_I915_GEM_GET_CACHEING0x30
#define DRM_I915_REG_READ0x31
+#define DRM_I915_GET_RESET_STATS 0x32
#define DRM_IOCTL_I915_INIT DRM_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_CREATEDRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
#define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
#define DRM_IOCTL_I915_REG_READ DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
+#define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
/* Allow drivers to submit batchbuffers directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -943,4 +945,21 @@ struct drm_i915_reg_read {
__u64 offset;
__u64 val; /* Return value */
};
+
+struct drm_i915_reset_stats {
+ __u32 ctx_id;
+ __u32 flags;
+
+ /* All resets since boot/module reload, for all contexts */
+ __u32 reset_count;
+
+ /* Number of batches lost when active in GPU, for this context */
+ __u32 batch_active;
+
+ /* Number of batches lost pending for execution, for this context */
+ __u32 batch_pending;
+
+ __u32 pad;
+};
+
#endif /* _I915_DRM_H_ */
diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
index 7b28a70..34a5750 100644
--- a/intel/intel_bufmgr.h
+++ b/intel/intel_bufmgr.h
@@ -249,6 +249,11 @@ int drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
uint32_t offset,
uint64_t *result);
+int drm_intel_get_reset_stats(drm_intel_context *ctx,
+ uint32_t *reset_count,
+ uint32_t *active,
+ uint32_t *pending);
+
/** @{ Compatibility defines to keep old code building despite the symbol
rename
* from dri_* to drm_intel_*
*/
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index dbadc52..0b9252e 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -3029,6 +3029,40 @@ drm_intel_gem_context_get_hw_context_id(const
drm_intel_context *ctx)
}
int
+drm_intel_get_reset_stats(drm_intel_context *ctx,
+ uint32_t *reset_count,
+ uint32_t *active,
+ uint32_t *pending)
+{
+ drm_intel_bufmgr_gem *bufmgr_gem;
+ struct drm_i915_reset_stats stats;
+ int ret;
+
+ if (ctx == NULL)
+ return -EINVAL;
+
+ VG_CLEAR(stats);
+
+ bufmgr_gem = (drm_intel_bufmgr_gem *)ctx-bufmgr;
+ stats.ctx_id = ctx-ctx_id;
+ ret = drmIoctl(bufmgr_gem-fd,
+DRM_IOCTL_I915_GET_RESET_STATS,
+stats);
+ if (ret == 0) {
+ if (reset_count != NULL)
+ *reset_count = stats.reset_count;
+
+ if (active != NULL)
+ *active = stats.batch_active;
+
+ if (pending != NULL)
+ *pending = stats.batch_pending;
+ }
+
+ return ret;
+}
+
+int
drm_intel_reg_read(drm_intel_bufmgr *bufmgr,
uint32_t offset,
uint64_t
Re: [Intel-gfx] [PATCH] drm/i915: flush cursors harder
On Mon, Nov 04, 2013 at 06:58:13PM +0200, Ville Syrjälä wrote: On Mon, Nov 04, 2013 at 05:34:41PM +0100, Daniel Vetter wrote: On Mon, Nov 04, 2013 at 06:02:24PM +0200, Ville Syrjälä wrote: On Mon, Nov 04, 2013 at 08:13:45AM +0100, Daniel Vetter wrote: Apparently they need the same treatment as primary planes. This fixes modesetting failures because of stuck cursors (!) on Thomas' i830M machine. What treatment? Primary planes don't need any extra posting reads AFAIK. If you look at flush_primary_plane it's definitely there. So I've copied it over (it's just a real I915_READ, not a posting one). The regular read is there just so that we don't modify the surface base address. We should be able to replace the read w/ recomputing the address. I've figured while at it I'll also roll it out for the ivb 3 pipe version of this function. I didn't do this for i845/i865 since Bspec says the update mechanism works differently, and there's some additional rules about what can be updated in which order. Tested-by: Thomas Richter t...@math.tu-berlin.de I didn't see an explicit note from Thomas saying that he tested it. It's burried somewhere in the thread, but he said that with the 2 earlier dvo patches + this one here the lvds-only use-case now works well. Before that he had issues with the display just showing a cursor and the kernel complaining about the cursor being stuck in the enabled position when trying to re-enable it. From the mails, I couldn't figure out if he tried them all or just the two patches you posted earlier. Well I've written that patch to combat a WARN backtrace where the cursor somehow didn't turn of. Thomas said he hasn't seen it since, so might have worked. In any case it shouldn't be harmful, so I've merged it to -fixes. -Daniel -Daniel Cc: sta...@vger.kernel.org Cc: Thomas Richter t...@math.tu-berlin.de Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_display.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f34252d134b6..04d2699f51b4 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7123,7 +7123,9 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, u32 base) intel_crtc-cursor_visible = visible; } /* and commit changes on next vblank */ + POSTING_READ(CURCNTR(pipe)); I915_WRITE(CURBASE(pipe), base); + POSTING_READ(CURBASE(pipe)); } static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) @@ -7152,7 +7154,9 @@ static void ivb_update_cursor(struct drm_crtc *crtc, u32 base) intel_crtc-cursor_visible = visible; } /* and commit changes on next vblank */ + POSTING_READ(CURCNTR_IVB(pipe)); I915_WRITE(CURBASE_IVB(pipe), base); + POSTING_READ(CURBASE_IVB(pipe)); } /* If no-part of the cursor is visible on the framebuffer, then the GPU may hang... */ -- 1.8.4.rc3 ___ 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Ville Syrjälä Intel OTC -- 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] [igt] Making the test-suite easier to run
On Fri, Nov 15, 2013 at 05:41:28PM +, Damien Lespiau wrote: On Fri, Nov 15, 2013 at 06:23:18PM +0100, Daniel Vetter wrote: - I think we need to make it very clear that piglit should still be developed upstream. So local changes shouldn't be allowed at all imo. Sure, I'll wait until my patches are upstreamed to resend the series without the local patches. Afaics that would only affect tests/igt.tests - can't we fix that by replicating the symlink, too? I was thinking to completely remove igt.tests from upstream piglit. There isn't anything special about the location of igt.tests, you just need to give a (absolute) path to it when launching piglit-run.py and not being in the piglit-run.py directory. As igt.test is really coupled with igt, it makes sense to carry it in our tree, IMO. It's also coupled with piglit. If we move it completely then enabling new piglit features will be a bit a pain. The only reason I can see to keep it in igt only is if we want to change the way we generate the test list (the current way with Makefile target will probably not amuse Oscar). But that's about the only thing. - The makefile target looks like a script. I think it'd be better to extract it as a real script. Can do. - I'm not too terribly sold on the convenience script. Imo it shouldn't be more than executable documentation, since I'm a bit afraid that we'll add neat features (like fancy resume with auto-blocking of crashing tests) to it that would better be done in upstream piglit to benefit everyone. Point taken. We can judge when adding a feature if it'd be better to do it upstream of if it's just a convenience wrapper for us. But what I really want is the convenience and well defined runs that everyone can replicate (a lof of details to remember, concurrent Vs not-concurrent, how to generate the HTML report, ...). And I'd like to add more: eg. give the 10 tests that take the longest time in the run so people can look at them and try to make them faster, ... Also I really want quicker subsets of the test-suite, people don't run the full test-suite everytime they work on a series and this just step 1/ towards that goal. Running a subset is better than running nothing at all :) Yeah, like I've said it makes sense. I just have the long-term dream of pimping piglit into a generally useful gfx testrunner, maybe even with a bit of code to support centrally stored test results. Would help a lot for my own little lab here ;-) Cheers, 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] drm/i915: Fix module unloading with DRM_I915_UMS=n
On Fri, Nov 15, 2013 at 05:16:33PM +0100, Daniel Vetter wrote:
Oops, makes testing early boot failures in i915.ko a bit more pain, so
let's fix it.
v2: We already have a bit of static storage to track this (Chris).
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
How about just fixing the core not to die?
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index f00d7a9..3b9c7ce 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -375,13 +375,13 @@ int drm_pci_init(struct drm_driver *driver, struct
pci_driver *pdriver)
DRM_DEBUG(\n);
+ if (driver-driver_features DRIVER_MODESET)
+ return pci_register_driver(pdriver);
+
INIT_LIST_HEAD(driver-device_list);
driver-kdriver.pci = pdriver;
driver-bus = drm_pci_bus;
- if (driver-driver_features DRIVER_MODESET)
- return pci_register_driver(pdriver);
-
/* If not using KMS, fall back to stealth mode manual scanning. */
for (i = 0; pdriver-id_table[i].vendor != 0; i++) {
pid = pdriver-id_table[i];
@@ -462,6 +462,11 @@ void drm_pci_exit(struct drm_driver *driver, struct
pci_driver *pdriver)
struct drm_device *dev, *tmp;
DRM_DEBUG(\n);
+ if (!driver-kdriver.pci)
+ return;
+
+ WARN_ON(driver-kdriver.pci != pdriver);
+
if (driver-driver_features DRIVER_MODESET) {
pci_unregister_driver(pdriver);
} else {
We can drop the redundant pdriver later.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix module unloading with DRM_I915_UMS=n
On Fri, Nov 15, 2013 at 08:58:12PM +, Chris Wilson wrote:
On Fri, Nov 15, 2013 at 05:16:33PM +0100, Daniel Vetter wrote:
Oops, makes testing early boot failures in i915.ko a bit more pain, so
let's fix it.
v2: We already have a bit of static storage to track this (Chris).
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
How about just fixing the core not to die?
This is for the disabled UMS code where we silently don't register
anything. So there's also nothing to clean up, i.e. we've called
drm_pci_exit without drm_pci_init. I don't think this is something we
should allow in the core.
-Daniel
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index f00d7a9..3b9c7ce 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -375,13 +375,13 @@ int drm_pci_init(struct drm_driver *driver, struct
pci_driver *pdriver)
DRM_DEBUG(\n);
+ if (driver-driver_features DRIVER_MODESET)
+ return pci_register_driver(pdriver);
+
INIT_LIST_HEAD(driver-device_list);
driver-kdriver.pci = pdriver;
driver-bus = drm_pci_bus;
- if (driver-driver_features DRIVER_MODESET)
- return pci_register_driver(pdriver);
-
/* If not using KMS, fall back to stealth mode manual scanning. */
for (i = 0; pdriver-id_table[i].vendor != 0; i++) {
pid = pdriver-id_table[i];
@@ -462,6 +462,11 @@ void drm_pci_exit(struct drm_driver *driver, struct
pci_driver *pdriver)
struct drm_device *dev, *tmp;
DRM_DEBUG(\n);
+ if (!driver-kdriver.pci)
+ return;
+
+ WARN_ON(driver-kdriver.pci != pdriver);
+
if (driver-driver_features DRIVER_MODESET) {
pci_unregister_driver(pdriver);
} else {
We can drop the redundant pdriver later.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
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
