[Intel-gfx] Improvements and fixes for Intel ddx swap scheduling/timestamping.
Hi, a series of three patches to improve the dri2 swap scheduling and timestamping for the current intel ddx. The first one enables proper OML_sync_control timestamping while triple-buffering is enabled and XOrg 1.12+ with DRI2SwapLimit support is in use. So far, timestamping was unuseable with triple-buffering, only worked with double-buffering. The second one repairs the broken pageflip swap scheduling, which is apparently in a frightening state for timing sensitive apps since a year, due to a tiny but really ugly bug. In a perfect implementation of Murphy's law, the same commit that broke the scheduling also disabled the builtin correctness checks that were supposed to catch such bugs. The third one proposes to revert 'SwapBuffersWait' to its old behaviour where it didn't affect pageflipping. I just can't think of a case where the current behaviour makes any sense, not even for benchmarking? But maybe i'm overlooking something. All patches were tested against an Intel 945-GME gpu. I don't really care about the 'SwapBuffersWait' patch one way or the other, but the first two are crucial to make the intel ddx useable in a painless and safe way again for users of timing sensitive applications. Thanks, -mario ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] ddx/dri2: Make triple-buffering compatible with timestamping on Xorg 1.12+
This patch adds support for OML_sync_control compliant pageflip
completion timestamping while triple-buffering is enabled and
the ddx is running on Xorg server 1.12 or later.
It makes use of the DRI2SwapLimit api to allow up to two
pending flips without throttling of the client, then defers
invocation of DRI2SwapComplete() until the corresponding
pageflips actually complete, just as in the double-buffering case,
allowing for proper timestamping and glXWaitForSbcOML() behaviour.
This should not impact triple-buffering performance.
On server versions = 1.11 without swaplimit api, triple-buffering
is achieved by sacrificing OML_sync_control compliance, as in the
old implementation.
Tested against server without swaplimit api and 1.13 with swaplimit
api, both with and without triplebuffering enabled.
Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
src/intel_dri.c | 67 ---
1 file changed, 59 insertions(+), 8 deletions(-)
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 64cb567..126acb2 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -310,6 +310,15 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int
attachment,
drawable = (get_drawable_pixmap(drawable)-drawable);
is_glamor_pixmap = TRUE;
}
+
+#if DRI2INFOREC_VERSION = 6
+ /* If swaplimit api supported, use it to tell server we are
+* triple-buffering capable. This allows triple-buffering
+* without need for hacks which compromise time-stamping.
+*/
+ if (drawable-type == DRAWABLE_WINDOW)
+ DRI2SwapLimit(drawable, intel-use_triple_buffer ? 2 :
1);
+#endif
}
if (pixmap == NULL) {
@@ -815,6 +824,20 @@ static drm_intel_bo
*get_pixmap_bo(I830DRI2BufferPrivatePtr priv)
return bo;
}
+#if DRI2INFOREC_VERSION = 6
+static Bool
+I830DRI2SwapLimitValidate(DrawablePtr draw, int swap_limit)
+{
+ ScrnInfoPtr pScrn = xf86ScreenToScrn(draw-pScreen);
+ struct intel_screen_private *intel = intel_get_screen_private(pScrn);
+
+ if ((swap_limit 1 ) || (swap_limit (intel-use_triple_buffer ? 2 :
1)))
+ return FALSE;
+
+ return TRUE;
+}
+#endif
+
/*
* Our internal swap routine takes care of actually exchanging, blitting, or
* flipping buffers as necessary.
@@ -914,10 +937,17 @@ I830DRI2ScheduleFlip(struct intel_screen_private *intel,
/* Then flip DRI2 pointers and update the screen pixmap */
I830DRI2ExchangeBuffers(intel, info-front, info-back);
+
+#if DRI2INFOREC_VERSION 6
+ /* Only needed on Xorg = 1.11 server, which doesn't have swaplimit
+* api to do this cleanly. Breaks OML_sync_control timestamping.
+*/
DRI2SwapComplete(info-client, draw, 0, 0, 0,
DRI2_EXCHANGE_COMPLETE,
info-event_complete,
info-event_data);
+#endif
+
return TRUE;
}
@@ -1041,14 +1071,22 @@ void I830DRI2FlipEventHandler(unsigned int frame,
unsigned int tv_sec,
dixLookupDrawable(drawable, flip_info-drawable_id,
serverClient,
M_ANY, DixWriteAccess);
-
- /* We assume our flips arrive in order, so we don't check the frame */
- switch (flip_info-type) {
- case DRI2_SWAP:
- if (!drawable)
- break;
-
- /* Check for too small vblank count of pageflip completion,
taking wraparound
+ /* Perform consistency check, final timestamping and swap completion
here iff:
+* - This is a pageflip completion for a classic double-buffered swap.
+* - This is a pageflip completion for a triple-buffered swap and the
XOrg 1.12+
+* server supports the swap limit api, so we were able to defer swap
completion
+* until this point without negative impact on performance.
+*
+* - This allows OML_sync_control spec compliant timestamping.
+*
+* On older servers we already mark the swap as completed ahead of its
completion in
+* I830DRI2ScheduleFlip to allow triple-buffering at the cost of broken
timestamping.
+*/
+ if (drawable ((flip_info-type == DRI2_SWAP) ||
+((DRI2INFOREC_VERSION = 6) (flip_info-type ==
DRI2_SWAP_CHAIN {
+ /* We assume our flips arrive in order, so we don't check the
frame.
+*
+* Check for too small vblank count of pageflip completion,
taking wraparound
* into account. This usually means some defective kms pageflip
completion,
* causing wrong (msc, ust) return values and possible visual
corruption.
*/
@@ -1072,6 +1110,11 @@ void I830DRI2FlipEventHandler(unsigned int frame,
unsigned int tv_sec,
[Intel-gfx] [PATCH 2/3] ddx/dri2: Repair broken pageflip swap scheduling.
Commit 7538be3315b8683b05e8f6b22023baadcc0bc4da together
with DRI2/OpenGL triple-buffering support added an
optimization which breaks kms pageflip swap scheduling for most
meaningful use cases and thereby violates the OML_sync_control,
GLX_SGI_swap_control, GLX_swap_control and MESA_swap_control
specs, except for the trivial case of a glXSwapBuffers call
with swap_interval == 1.
This small modification allows to keep the optimization in
the intended way, while removing the hilarious side effects
for timing sensitive applications.
Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
src/intel_dri.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 126acb2..8786bf4 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -1275,9 +1275,6 @@ I830DRI2ScheduleSwap(ClientPtr client, DrawablePtr draw,
DRI2BufferPtr front,
* the swap.
*/
if (divisor == 0 || current_msc *target_msc) {
- if (flip I830DRI2ScheduleFlip(intel, draw, swap_info))
- return TRUE;
-
vbl.request.type =
DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT |
pipe_select(pipe);
@@ -1295,6 +1292,25 @@ I830DRI2ScheduleSwap(ClientPtr client, DrawablePtr draw,
DRI2BufferPtr front,
if (current_msc = *target_msc)
*target_msc = current_msc;
+ /* If pageflip is requested for the next possible vblank,
+* then avoid the roundtrip to the kernels vblank event
+* delivery and schedule the pageflip for next vblank
+* directly. This can't be done for any other case, as
+* it would violate the OML_sync_control spec and
+* SGI/MESA/GLX_swap_control spec!
+*/
+ if (flip (current_msc == *target_msc)
+ I830DRI2ScheduleFlip(intel, draw, swap_info)) {
+ /* Create approximate target vblank of flip-completion,
+* so basic consistency checks and swap_interval still
+* work correctly.
+*/
+ *target_msc += flip;
+ swap_info-frame = *target_msc;
+
+ return TRUE;
+ }
+
vbl.request.sequence = *target_msc;
vbl.request.signal = (unsigned long)swap_info;
ret = drmWaitVBlank(intel-drmSubFD, vbl);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] ddx/dri2: Prevent option 'SwapBuffersWait' from disabling pageflip.
Commit 1d102cc6ed21d1c4afa47800eecd24b9d663f689 introduced a
change, where setting option 'SwapBuffersWait' to 'off' disables
kms pageflipping of fullscreen windows.
Afaics this change had no benefit, but only downsides:
1. Apps which don't want to throttle their swaps to video refresh
rate and therefore set swap_limit to zero, will run through
the non-vsynced, tearing copyswap path, as before the change.
2. Apps which set their swap_limit 0, because they want throttled
and vsynced swaps, will still get throttled to video refresh rate,
regardless of the 'SwapBuffersWait' 'off', because their swaps
are still scheduled via the normal kernel vblank events
path, as before the change. The only differences are that
more inefficient copyswaps instead of kms pageflips are used
for fullscreen drawables, timestamping gets unreliable and
tearing is present at the top of the screen due to lack of vsync.
Therefore no longer disable pageflipping if SwapBuffersWait is off.
Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
src/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel_display.c b/src/intel_display.c
index b2a5904..ac3dd8f 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -1731,7 +1731,7 @@ Bool intel_mode_pre_init(ScrnInfoPtr scrn, int fd, int
cpp)
gp.value = has_flipping;
(void)drmCommandWriteRead(intel-drmSubFD, DRM_I915_GETPARAM, gp,
sizeof(gp));
- if (has_flipping intel-swapbuffers_wait) {
+ if (has_flipping) {
xf86DrvMsg(scrn-scrnIndex, X_INFO,
Kernel page flipping support detected, enabling\n);
intel-use_pageflipping = TRUE;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Sun, 07 Oct 2012 15:01:17 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote: Hi Ben, Please consider cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 for application to the 3.2.y tree. It adds a PCI id to the i915 driver, making kms work. It was applied during the 3.4-rc2 cycle, so newer stable kernels don't need it. Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok (thanks!). Note that pre-2.4.34 versions of libdrm don't cope well with that card, with or without this patch: [...] - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, X freezes at startup. No regressions means you probably shouldn't take this patch without a safety to work around the old X userspace, [...] Then this workaround is also required in mainline. And once that's done, I can take both patches. The bugs Jonathan mentions are both in userspace packages; not recognising the existence of Bromlow, and then misprogramming it. There are no other kernel patches required specifically for this chipset, afaik. -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] drm/i915: Set guardband clipping workaround bit in the right register.
A previous patch, namely: commit bf97b276ca04cee9ab65ffd378fa8e6aedd71ff6 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Wed Apr 11 20:42:41 2012 +0200 drm/i915: implement w/a for incorrect guarband clipping accidentally set bit 5 in 3D_CHICKEN, which has nothing to do with clipping. This patch changes it to be set in 3D_CHICKEN3, where it belongs. The game Dante demonstrates random clipping issues when guardband clipping is enabled and bit 5 of 3D_CHICKEN3 isn't set. So the workaround is actually necessary. Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Oliver McFadden oliver.mcfad...@linux.intel.com Acked-by: Paul Menzel paulepan...@users.sourceforge.net Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index a828e90..438bb7a 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -521,7 +521,7 @@ */ # define _3D_CHICKEN2_WM_READ_PIPELINED(1 14) #define _3D_CHICKEN3 0x02090 -#define _3D_CHICKEN_SF_DISABLE_FASTCLIP_CULL (1 5) +#define _3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL (1 5) #define MI_MODE0x0209c # define VS_TIMER_DISPATCH (1 6) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 82ca172..7ac8a48 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3410,8 +3410,8 @@ static void gen6_init_clock_gating(struct drm_device *dev) GEN6_RCCUNIT_CLOCK_GATE_DISABLE); /* Bspec says we need to always set all mask bits. */ - I915_WRITE(_3D_CHICKEN, (0x 16) | - _3D_CHICKEN_SF_DISABLE_FASTCLIP_CULL); + I915_WRITE(_3D_CHICKEN3, (0x 16) | + _3D_CHICKEN3_SF_DISABLE_FASTCLIP_CULL); /* * According to the spec the following bits should be -- 1.7.12.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] i915 problems with suspend to disk
Hi, On 3.6, I've got a problem with my video driver after resuming from suspend-to-disk: the lower part of the display flickers, rapidly but irregularly (think of a neon sign in a bad film noir), flicking between the correct display and... something else, it's hard to see what. Shutting the lid of the machine (to trigger a suspend-to-ram) and waking it up again fixes the flicker. In syslogs, I have nothing obvious on suspend, and this warning on resume: Oct 4 19:53:04 ruth kernel: [ 2892.184086] [ cut here ] Oct 4 19:53:04 ruth kernel: [ 2892.184114] WARNING: at drivers/gpu/drm/i915/intel_display.c:1225 intel_crtc_disable+0x52/0x86 [i915]() Oct 4 19:53:04 ruth kernel: [ 2892.184115] Hardware name: 0196CTO Oct 4 19:53:04 ruth kernel: [ 2892.184117] pipe B assertion failure (expected off, current on) Oct 4 19:53:04 ruth kernel: [ 2892.184188] Modules linked in: cpufreq_powersave cpufreq_userspace cpufreq_stats cpufreq_conservative rfcomm bnep binfmt_misc uinput nfsd auth_rpcgss nfs_acl nfs lockd fscache sunrpc ext4 jbd2 mbcache loop arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_conexant coretemp i915 snd_hda_intel snd_hda_codec drm_kms_helper iwlwifi snd_hwdep snd_pcm snd_page_alloc joydev snd_seq snd_seq_device snd_timer kvm_intel drm i2c_algo_bit thinkpad_acpi acpi_cpufreq nvram btusb bluetooth kvm crc16 cfg80211 microcode psmouse evdev i2c_i801 video rfkill wmi mperf i2c_core snd battery ac processor soundcore button btrfs crc32c libcrc32c zlib_deflate sha256_generic ablk_helper cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sd_mod crc_t10dif ums_realtek usb_storage uas thermal thermal_sys ahci libahci libata uhci_hcd scsi_mod ehci_hcd r8169 mii usbcore usb_common Oct 4 19:53:04 ruth kernel: [ 2892.184198] Pid: 4117, comm: kworker/u:3 Not tainted 3.6.0 #14 Oct 4 19:53:04 ruth kernel: [ 2892.184199] Call Trace: Oct 4 19:53:04 ruth kernel: [ 2892.184207] [8102bdc5] ? warn_slowpath_common+0x78/0x8c Oct 4 19:53:04 ruth kernel: [ 2892.184213] [8104afd3] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184216] [8102be71] ? warn_slowpath_fmt+0x45/0x4a Oct 4 19:53:04 ruth kernel: [ 2892.184221] [8104afd3] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184238] [a03fdae0] ? intel_crtc_disable+0x52/0x86 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184245] [a0273e47] ? drm_helper_disable_unused_functions+0xd0/0xfb [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184250] [a027461e] ? drm_helper_resume_force_mode+0xf1/0xff [drm_kms_helper] Oct 4 19:53:04 ruth kernel: [ 2892.184254] [8104afd3] ? async_schedule+0xc/0xc Oct 4 19:53:04 ruth kernel: [ 2892.184264] [a03dc17f] ? i915_drm_thaw+0xd4/0x10b [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184274] [a03dc4fc] ? i915_resume+0x3b/0x50 [i915] Oct 4 19:53:04 ruth kernel: [ 2892.184279] [81193f21] ? pci_legacy_resume+0x39/0x39 Oct 4 19:53:04 ruth kernel: [ 2892.184284] [812196f7] ? dpm_run_callback.isra.5+0x26/0x54 Oct 4 19:53:04 ruth kernel: [ 2892.184289] [81219fe1] ? device_resume+0xd0/0x110 Oct 4 19:53:04 ruth kernel: [ 2892.184292] [8121a035] ? async_resume+0x14/0x38 Oct 4 19:53:04 ruth kernel: [ 2892.184296] [8104b070] ? async_run_entry_fn+0x9d/0x175 Oct 4 19:53:04 ruth kernel: [ 2892.184300] [81041a1a] ? process_one_work+0x184/0x2a3 Oct 4 19:53:04 ruth kernel: [ 2892.184304] [810426f1] ? worker_thread+0x1fe/0x29f Oct 4 19:53:04 ruth kernel: [ 2892.184307] [810424f3] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184310] [810424f3] ? manage_workers+0x223/0x223 Oct 4 19:53:04 ruth kernel: [ 2892.184315] [81045adf] ? kthread+0x67/0x6f Oct 4 19:53:04 ruth kernel: [ 2892.184319] [812fe774] ? kernel_thread_helper+0x4/0x10 Oct 4 19:53:04 ruth kernel: [ 2892.184324] [81045a78] ? kthread_freezable_should_stop+0x3c/0x3c Oct 4 19:53:04 ruth kernel: [ 2892.184327] [812fe770] ? gs_change+0xb/0xb Oct 4 19:53:04 ruth kernel: [ 2892.184328] ---[ end trace 4e63ed9ed8ebc493 ]--- Hardware is a Lenovo Thinkpad Edge13, lspci says: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) aka 00:02.0 0300: 8086:2a42 (rev 07) Let me know if you need more information. I can probably manage a bisect if necessary -- it's easily repeatable as a bug. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Ceci n'est pas une pipe: | --- signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [RFC] [PATCH 00/14] HPD/connector-polling rework
On Thu, May 24, 2012 at 3:26 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, I've got fed up with our sorry state of connector detection and rampant edid re and rere-reading. This patch series lays the groundwork in the drm helpers so that drivers can avoid all this madness (at least on working hw) and properly cache the edid. With the additional changes for drm/i915, the edid is now read _once_ per plug event (or at boot-up/resume time). A further step would be to integrate the hotplug handling into the driver itself and only call -detect on the connectors for which the irq handler received a hotplug event. By adding POLL_FORCE drivers can get back the old behaviour of calling -detect every time probe_single_connector is called from userspace. I've splattered that over all drivers where I've thought it might be required. Note though that setting this doesn't avoid all regressions - the regular output poll work will still ignore any connectors with POLL_HPD set. If a driver/hw with broken hpd got away due to this, this will break stuff. But that should be easy to fix by admitting the defeat and setting POLL_CONNECT|DISCONNECT directly. If other people want to convert over their drivers, the following steps are required: - Ensure that the connector status is unknown every time the driver could have missed a hpd event (e.g. after resume). drm_mode_config_reset will do that for you. - Drop the POLL_FORCE flag for connectors where hdp is fully reliable. - Implement edid caching - that's a nice way to figure out whether hpd is actually reliable, because if it isn't, this step will ensure that you get bug reports because the the edid won't ever get updated ;-) - Optionally teach the driver some smarts about which specific connectors actually got a hotplug event. Mostly useful on cheap hw (like intel's) that can't distinguish between hdmi and dp without trying some aux channel transfers. As you can guess from the patch series, I've discovered the hard way that i915 sdvo support is totally broken. Tested on most of the intel machines I have and also quickly on my radeon hd5000. Comments, flames, ideas and test reports highly welcome. This set looks good to me. Do you have plans to revive this? At least the common drm ones are much better than what we currently have. Alex Cheers, Daniel Daniel Vetter (14): drm: extract drm_kms_helper_hotplug_event drm: handle HDP and polled connectors separately drm: introduce DRM_CONNECTOR_POLL_FORCE drm/i915: set POLL_FORCE for sdvo outputs drm: properly init/reset connector status drm: kill unnecessary calls to connector-detect drm: don't start the poll engine in probe_single_connector drm: don't unnecessarily enable the polling work drm: don't poll forced connectors drm/i915: cache crt edid drm/i915: cache dp edid drm/i915: cache hdmi edid drm/i915/sdvo: implement correct return value for -get_modes drm/i915: s/mdelay/msleep/ in the sdvo detect function drivers/gpu/drm/drm_crtc.c|6 ++- drivers/gpu/drm/drm_crtc_helper.c | 76 ++--- drivers/gpu/drm/exynos/exynos_drm_connector.c |2 + drivers/gpu/drm/gma500/cdv_intel_crt.c|2 + drivers/gpu/drm/gma500/cdv_intel_hdmi.c |2 + drivers/gpu/drm/gma500/mdfld_dsi_output.c |1 + drivers/gpu/drm/gma500/oaktrail_hdmi.c|2 + drivers/gpu/drm/gma500/psb_intel_sdvo.c |2 + drivers/gpu/drm/i915/intel_crt.c | 28 +++-- drivers/gpu/drm/i915/intel_dp.c | 47 +++ drivers/gpu/drm/i915/intel_drv.h |2 + drivers/gpu/drm/i915/intel_hdmi.c | 48 ++-- drivers/gpu/drm/i915/intel_modes.c| 18 +- drivers/gpu/drm/i915/intel_sdvo.c | 45 +-- drivers/gpu/drm/i915/intel_tv.c |3 +- drivers/gpu/drm/nouveau/nouveau_connector.c |1 + drivers/gpu/drm/radeon/radeon_connectors.c|5 ++ drivers/gpu/drm/udl/udl_connector.c |2 + drivers/staging/omapdrm/omap_connector.c |2 + include/drm/drm_crtc.h|5 ++ include/drm/drm_crtc_helper.h |1 + 21 files changed, 208 insertions(+), 92 deletions(-) -- 1.7.7.6 ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] [PATCH 00/14] HPD/connector-polling rework
On Thu, Oct 4, 2012 at 1:16 PM, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Oct 04, 2012 at 12:07:01PM -0400, Alex Deucher wrote: On Thu, May 24, 2012 at 3:26 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, I've got fed up with our sorry state of connector detection and rampant edid re and rere-reading. This patch series lays the groundwork in the drm helpers so that drivers can avoid all this madness (at least on working hw) and properly cache the edid. With the additional changes for drm/i915, the edid is now read _once_ per plug event (or at boot-up/resume time). A further step would be to integrate the hotplug handling into the driver itself and only call -detect on the connectors for which the irq handler received a hotplug event. By adding POLL_FORCE drivers can get back the old behaviour of calling -detect every time probe_single_connector is called from userspace. I've splattered that over all drivers where I've thought it might be required. Note though that setting this doesn't avoid all regressions - the regular output poll work will still ignore any connectors with POLL_HPD set. If a driver/hw with broken hpd got away due to this, this will break stuff. But that should be easy to fix by admitting the defeat and setting POLL_CONNECT|DISCONNECT directly. If other people want to convert over their drivers, the following steps are required: - Ensure that the connector status is unknown every time the driver could have missed a hpd event (e.g. after resume). drm_mode_config_reset will do that for you. - Drop the POLL_FORCE flag for connectors where hdp is fully reliable. - Implement edid caching - that's a nice way to figure out whether hpd is actually reliable, because if it isn't, this step will ensure that you get bug reports because the the edid won't ever get updated ;-) - Optionally teach the driver some smarts about which specific connectors actually got a hotplug event. Mostly useful on cheap hw (like intel's) that can't distinguish between hdmi and dp without trying some aux channel transfers. As you can guess from the patch series, I've discovered the hard way that i915 sdvo support is totally broken. Tested on most of the intel machines I have and also quickly on my radeon hd5000. Comments, flames, ideas and test reports highly welcome. This set looks good to me. Do you have plans to revive this? At least the common drm ones are much better than what we currently have. The issue I've meanwhile discovered with hpd handling is that we really need the smarts in the driver to only do probing on native hdmi/dp outputs if we have a hpd irq for that specific port: Since we have 2 encoders for the same port, if e.g. dp is enabled and we do edid probing on the hdmi encoder/connector the display might get unhappy, which can happen even with these patches applied e.g. when pluggin in a 2nd display. So the new plan (for 3.8 hopefully) is to revamp the i915-internal hpd handling and keep on using the crtc helper stuff. For connectors with reliable hpd we'd simply return the tracked stated in -detect without touching the hw at all. So I don't think we need any changes in the hotplug/polling helper code. And looking again at these patches, they're a rather decent kludge and it's probably better to do this all in the drivers. Since the helper code sets the force parameter to false for all the background polling, you can just return any driver-internal cached state. And when force=true you could invalidate that cached state or do some additional (more expensive) detection. Well the current code skips all hotplug event propagation if the poll option is disabled (even for hpd capable connectors) which is fail so the first few patches still seem like a win. I guess you are not planning to use any of the current common hpd code? If so, do you mind if we pull at least the first few patches in in the interim for other drivers? Alex In short: No plans to revive this, but certainly plans to improve the drm/i915 hpd handling. 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] i915 problems with suspend to disk
On Thu, Oct 04, 2012 at 09:31:39PM +0200, Daniel Vetter wrote: On Thu, Oct 04, 2012 at 08:20:17PM +0100, Hugo Mills wrote: On 3.6, I've got a problem with my video driver after resuming from suspend-to-disk: the lower part of the display flickers, rapidly but irregularly (think of a neon sign in a bad film noir), flicking between the correct display and... something else, it's hard to see what. Shutting the lid of the machine (to trigger a suspend-to-ram) and waking it up again fixes the flicker. In syslogs, I have nothing obvious on suspend, and this warning on resume: [snip] Hardware is a Lenovo Thinkpad Edge13, lspci says: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) aka 00:02.0 0300: 8086:2a42 (rev 07) Let me know if you need more information. I can probably manage a bisect if necessary -- it's easily repeatable as a bug. Before you do a bisect, can you try the drm-intel-fixes branch from http://cgit.freedesktop.org/~danvet/drm-intel or a bit more risky, latest upstream git? That contains a completely rewritten modeset code, which might fix this already. To fix the breakage on 3.6 I guess we need a bisect - at least I don't have any idea off-hand what could have gone wrong here. Thank you for the quick response. The drm-intel-fixes branch seems to have done the trick. No more flickering. I think we can call this one fixed. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- I always felt that as a C programmer, I --- was becoming typecast. signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: In practice we never want the timestamps for vblank and page flip events to be affected by time adjustments, so in addition to the gettimeofday timestamps we used so far add support for raw monotonic timestamps. For backward compatibility use flags to select between the old and new timestamp format. Note that with this change we will save the timestamp in both formats, for cases where multiple clients are expecting an event notification in different time formats. I wonder if all this trouble is really necessary. I honestly can't imagine any user of this API requiring non-monotonic timestamps and breaking with monotonic ones. I think it was simply a mistake that we didn't make them monotonic in the first place (or maybe it wasn't even possible when this API was first introduced). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Fre, 2012-10-05 at 16:59 +0300, Imre Deak wrote: On Fri, 2012-10-05 at 15:55 +0200, Michel Dänzer wrote: On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote: In practice we never want the timestamps for vblank and page flip events to be affected by time adjustments, so in addition to the gettimeofday timestamps we used so far add support for raw monotonic timestamps. For backward compatibility use flags to select between the old and new timestamp format. Note that with this change we will save the timestamp in both formats, for cases where multiple clients are expecting an event notification in different time formats. I wonder if all this trouble is really necessary. I honestly can't imagine any user of this API requiring non-monotonic timestamps and breaking with monotonic ones. I think it was simply a mistake that we didn't make them monotonic in the first place (or maybe it wasn't even possible when this API was first introduced). Yea, I'd rather simply switch over to monotonic timestamps too. But that would break apps that already compare against the wall time for whatever purpose (for example A/V sync). Are there actually any such apps in the real world? Do they work when the wall time jumps? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Align the retire_requests worker to the nearest second
On 10/5/2012 6:53 AM, Chris Wilson wrote:
By using round_jiffies() we can align the wakeup of our worker to the
nearest second in order to batch wakeups and reduce system load, which
is useful for unimportant coarse tasks like our retire_requests.
Suggested-by: Arjan van de Ven ar...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Arjan van de Ven ar...@linux.intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8e05d53..706f481 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2084,6 +2084,11 @@ i915_gem_next_request_seqno(struct intel_ring_buffer
*ring)
return ring-outstanding_lazy_request;
}
+static unsigned long round_jiffies_delay(unsigned long delay)
+{
+ return round_jiffies_relative(delay) - jiffies;
+}
this is buggy
+
int
i915_add_request(struct intel_ring_buffer *ring,
struct drm_file *file,
@@ -2155,7 +2160,8 @@ i915_add_request(struct intel_ring_buffer *ring,
}
if (was_empty) {
queue_delayed_work(dev_priv-wq,
-dev_priv-mm.retire_work, HZ);
+dev_priv-mm.retire_work,
+round_jiffies_delay(HZ));
when used like this
round_jiffies() rounds absolute jiffies towards the next second
round_jiffies_relative() already subtracts jiffies from the result, like
the helper that you're trying to invent here does ;=)
doing that double up is a bad idea.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Fri, Oct 5, 2012 at 7:37 AM, Imre Deak imre.d...@intel.com wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ab1ef15..056e810 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6247,7 +6247,6 @@ static void do_intel_finish_page_flip(struct drm_device
*dev,
struct intel_unpin_work *work;
struct drm_i915_gem_object *obj;
struct drm_pending_vblank_event *e;
- struct timeval tvbl;
unsigned long flags;
/* Ignore early vblank irqs */
@@ -6264,12 +6263,13 @@ static void do_intel_finish_page_flip(struct
drm_device *dev,
intel_crtc-unpin_work = NULL;
if (work-event) {
- e = work-event;
- e-event.sequence = drm_vblank_count_and_time(dev,
intel_crtc-pipe, tvbl);
-
- e-event.tv_sec = tvbl.tv_sec;
- e-event.tv_usec = tvbl.tv_usec;
+ struct drm_vblank_time tvbl;
+ u32 seq;
+ e = work-event;
+ seq = drm_vblank_count_and_time(dev, intel_crtc-pipe, tvbl);
+ drm_set_event_seq_and_time(e-event, e-timestamp_raw, seq,
+ tvbl);
list_add_tail(e-base.link,
e-base.file_priv-event_list);
wake_up_interruptible(e-base.file_priv-event_wait);
btw, I wonder if we could just have a helper like:
int drm_send_page_flip_event(struct drm_device *dev, int crtc,
struct drm_pending_vblank_event *event);
Since most drivers have pretty much the same code for sending vblank
event after a page flip..
I guess not strictly related to monotonic timestamps, but it has been
a cleanup that I've been meaning to do for a while.. and I guess if
this was done first it wouldn't mean touching each driver (as much) to
add support for monotonic timestamps.
BR,
-R
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 7ddef8f..55c014a 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -272,7 +272,6 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev,
int crtc_id)
struct radeon_crtc *radeon_crtc = rdev-mode_info.crtcs[crtc_id];
struct radeon_unpin_work *work;
struct drm_pending_vblank_event *e;
- struct timeval now;
unsigned long flags;
u32 update_pending;
int vpos, hpos;
@@ -329,10 +328,13 @@ void radeon_crtc_handle_flip(struct radeon_device
*rdev, int crtc_id)
/* wakeup userspace */
if (work-event) {
+ struct drm_vblank_time now;
+ u32 seq;
+
e = work-event;
- e-event.sequence = drm_vblank_count_and_time(rdev-ddev,
crtc_id, now);
- e-event.tv_sec = now.tv_sec;
- e-event.tv_usec = now.tv_usec;
+ seq = drm_vblank_count_and_time(rdev-ddev, crtc_id, now);
+ drm_set_event_seq_and_time(e-event, e-timestamp_raw,
+ seq, now);
list_add_tail(e-base.link, e-base.file_priv-event_list);
wake_up_interruptible(e-base.file_priv-event_wait);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Fri, Oct 5, 2012 at 5:41 PM, Imre Deak imre.d...@intel.com wrote:
On Fri, 2012-10-05 at 16:18 -0600, Rob Clark wrote:
On Fri, Oct 5, 2012 at 7:37 AM, Imre Deak imre.d...@intel.com wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ab1ef15..056e810 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6247,7 +6247,6 @@ static void do_intel_finish_page_flip(struct
drm_device *dev,
struct intel_unpin_work *work;
struct drm_i915_gem_object *obj;
struct drm_pending_vblank_event *e;
- struct timeval tvbl;
unsigned long flags;
/* Ignore early vblank irqs */
@@ -6264,12 +6263,13 @@ static void do_intel_finish_page_flip(struct
drm_device *dev,
intel_crtc-unpin_work = NULL;
if (work-event) {
- e = work-event;
- e-event.sequence = drm_vblank_count_and_time(dev,
intel_crtc-pipe, tvbl);
-
- e-event.tv_sec = tvbl.tv_sec;
- e-event.tv_usec = tvbl.tv_usec;
+ struct drm_vblank_time tvbl;
+ u32 seq;
+ e = work-event;
+ seq = drm_vblank_count_and_time(dev, intel_crtc-pipe,
tvbl);
+ drm_set_event_seq_and_time(e-event, e-timestamp_raw,
seq,
+ tvbl);
list_add_tail(e-base.link,
e-base.file_priv-event_list);
wake_up_interruptible(e-base.file_priv-event_wait);
btw, I wonder if we could just have a helper like:
int drm_send_page_flip_event(struct drm_device *dev, int crtc,
struct drm_pending_vblank_event *event);
Since most drivers have pretty much the same code for sending vblank
event after a page flip..
I guess not strictly related to monotonic timestamps, but it has been
a cleanup that I've been meaning to do for a while.. and I guess if
this was done first it wouldn't mean touching each driver (as much) to
add support for monotonic timestamps.
Good idea, we should do this.
But if we want to reduce the diff from my changes then the proto should
rather be:
int drm_send_page_flip_event(struct drm_device *dev, int crtc,
struct drm_pending_vblank_event *event,
int seq, struct timeval *now);
do we need 'seq' and 'now'? I was sort of thinking that could all be
internal to the send_page_flip_event() fxn.. ie. like:
-
void drm_send_page_flip_event(struct drm_device *dev, int pipe,
struct drm_crtc *crtc, struct drm_pending_vblank_event *event)
{
struct timeval tnow, tvbl;
do_gettimeofday(tnow);
event-event.sequence = drm_vblank_count_and_time(dev, pipe, tvbl);
/* Called before vblank count and timestamps have
* been updated for the vblank interval of flip
* completion? Need to increment vblank count and
* add one videorefresh duration to returned timestamp
* to account for this. We assume this happened if we
* get called over 0.9 frame durations after the last
* timestamped vblank.
*
* This calculation can not be used with vrefresh rates
* below 5Hz (10Hz to be on the safe side) without
* promoting to 64 integers.
*/
if (10 * (timeval_to_ns(tnow) - timeval_to_ns(tvbl))
9 * crtc-framedur_ns) {
event-event.sequence++;
tvbl = ns_to_timeval(timeval_to_ns(tvbl) +
crtc-framedur_ns);
}
event-event.tv_sec = tvbl.tv_sec;
event-event.tv_usec = tvbl.tv_usec;
list_add_tail(event-base.link,
event-base.file_priv-event_list);
wake_up_interruptible(event-base.file_priv-event_wait);
}
-
well, this would be the pre-monotonic timestamp version.. and it is a
bit weird to have to pass in both crtc ptr and pipe #.. I don't see
anything obvious in drm core that links pipe # and crtc ptr, although
userspace seems to make this assumption about order of crtc's. But I
think that if() statement is only in i915 driver.. I assume because
you don't know if this will get called before or after
drm_handle_vblank()? I guess that shouldn't hurt for other drivers.
then each driver would just have something like:
-
if (work-event)
drm_send_page_flip_event(dev, intel_crtc-pipe, crtc,
work-event);
-
with struct timeval changing to struct drm_vblank_time with my changes.
I can do this if you agree - unless you have something ready.
I've locally split out this into a helper fxn in omapdrm, but haven't
got around to pushing it to core and updating other drivers. If you
want I can send a patch, but I guess it is easier to just include
something like this in your patchset. I'm ok
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote: Hi Ben, Please consider cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 for application to the 3.2.y tree. It adds a PCI id to the i915 driver, making kms work. It was applied during the 3.4-rc2 cycle, so newer stable kernels don't need it. Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok (thanks!). Note that pre-2.4.34 versions of libdrm don't cope well with that card, with or without this patch: [...] - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, X freezes at startup. No regressions means you probably shouldn't take this patch without a safety to work around the old X userspace, [...] Then this workaround is also required in mainline. And once that's done, I can take both patches. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Sun, 2012-10-07 at 15:11 +0100, Chris Wilson wrote: On Sun, 07 Oct 2012 15:01:17 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2012-10-01 at 03:24 -0700, Jonathan Nieder wrote: Hi Ben, Please consider cc22a938fc1d drm/i915: add Ivy Bridge GT2 Server entries, 2012-03-29 for application to the 3.2.y tree. It adds a PCI id to the i915 driver, making kms work. It was applied during the 3.4-rc2 cycle, so newer stable kernels don't need it. Maik Zumstrull tried it[1] on top of 3.2.30 and found it to work ok (thanks!). Note that pre-2.4.34 versions of libdrm don't cope well with that card, with or without this patch: [...] - with this patch, and with libdrm lacking 2.4.34~22 and 2.4.38~10, X freezes at startup. No regressions means you probably shouldn't take this patch without a safety to work around the old X userspace, [...] Then this workaround is also required in mainline. And once that's done, I can take both patches. The bugs Jonathan mentions are both in userspace packages; not recognising the existence of Bromlow, and then misprogramming it. Yes, I understand that. There are no other kernel patches required specifically for this chipset, afaik. If upgrading the kernel currently triggers a (more) serious bug in typical userland then the kernel should work around that. If I've misunderstood, and the userland behaviour is roughly equally broken with or without this change, then I'll be happy to take it. Ben. -- Ben Hutchings You can't have everything. Where would you put it? signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
On Mon, Oct 1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote: - without this patch, modern X errors out instead of starting, because the intel driver requires kms. (In a hypothetical better world, userspace would know to fall back to vesa or something.) I'd expect X to start with vesa or fbdev, rather than erroring out? Cheers, Julien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.2.y] drm/i915: add Ivy Bridge GT2 Server entries
Maik Zumstrull wrote: On Sun, Oct 7, 2012 at 7:26 PM, Julien Cristau jcris...@debian.org wrote: On Mon, Oct 1, 2012 at 03:24:32 -0700, Jonathan Nieder wrote: - without this patch, modern X errors out instead of starting, [...] I'd expect X to start with vesa or fbdev, rather than erroring out? There's a corner case when X and the kernel know about the graphics device, but libdrm doesn't, in which case an assertion in the X driver fails and X doesn't start. Upstream libdrm has been okay for a few releases. I think Julien means the case where the kernel does not know about the graphics device. From [1]: | 3.2 crashes as well, but not as hard as 3.4. With 3.2, X doesn't come | up, but you can switch to a console and reboot. 3.4 needs the reset | button. X should have been able to start using the vesa or fbdev driver. I'm not sure why that doesn't happen --- do you have an Xorg log from booting and trying to start X with a 3.2.y kernel without the drm/i915: add Ivy Bridge GT2 Server entries patch? Thanks, Jonathan [1] http://bugs.debian.org/684767 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove the disabling of VHR unit clock gating for HSW
On Fri, Oct 05, 2012 at 10:40:35AM -0300, Paulo Zanoni wrote: 2012/10/5 Damien Lespiau damien.lesp...@gmail.com: From: Damien Lespiau damien.lesp...@intel.com There's is another register (a read only, so no harm done) at 0x42020 on Haswell GPUs. Let's just remove the write from the copypaste that introduced haswell_init_clock_gating(). A note for the interested reader, it does seem we have a duplication of the 0x42020 register definition, hence the removal of 2 writes. That duplication could be the object of a later patch. Signed-off-by: Damien Lespiau damien.lesp...@intel.com Cc: Paulo Zanoni paulo.r.zan...@intel.com Nice catch! As you pointed, it seems that we're applying the same workaround twice in some functions. You fixed the problem in haswell_init_clock_gating by just removing both register writes, but could you also write a new patch to fix ivybridge_init_clock_gating and valleyview_init_clock_gating to not apply the same workaround twice? Maybe just remove the ILK_DSPCLK_GATE definitions and just use PCH_DSPCLK_GATE_D everywhere, removing duplicated code? Then we'd also have to check ironlake_init_clock_gating and gen6_init_clock_gating... Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com Tested-by: Paulo Zanoni paulo.r.zan...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 4/4] drm: add support for raw monotonic vblank timestamps
On Sat, Oct 06, 2012 at 03:49:16AM +0300, Imre Deak wrote:
On Fri, 2012-10-05 at 18:09 -0600, Rob Clark wrote:
/* Called before vblank count and timestamps have
* been updated for the vblank interval of flip
* completion? Need to increment vblank count and
* add one videorefresh duration to returned timestamp
* to account for this. We assume this happened if we
* get called over 0.9 frame durations after the last
* timestamped vblank.
*
* This calculation can not be used with vrefresh rates
* below 5Hz (10Hz to be on the safe side) without
* promoting to 64 integers.
*/
if (10 * (timeval_to_ns(tnow) - timeval_to_ns(tvbl))
9 * crtc-framedur_ns) {
event-event.sequence++;
tvbl = ns_to_timeval(timeval_to_ns(tvbl) +
crtc-framedur_ns);
}
This has been recently removed by danvet's drm/i915: don't frob the
vblank ts in finish_page_flip, though not yet committed, so we can do
away with it here too.
Yeah, I'd prefer if the common code doesn't have such hackes - this bit
here papered over some bugs in our driver code, but only partially
successfully ...
-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] [regression] 3.6-rc6, gpu hang with vaapi
Hi Guilherme, Sorry, I cannot reproduce this issue with the following Env: --- Kernel: (this is the same with yours) Version : 3.6.0rc6_stable_20120919+ Kernel: (drm-intel-fixes)b98b60167279df3acac9422c3c9820d9ebbcf9fb Some additional commit info: Author: Wang Xingchao xingchao.w...@intel.com Date: Thu Sep 13 07:43:22 2012 +0800 --- X: (This is newer than yours) Libdrm: (master)libdrm-2.4.39-9-g2426a6a7112ae62755408a371831eddbe2d89d99 Mesa: (9.0)b1ce5749b996d6ce3dcf9bbd1537c46d14e62adb Xserver: (server-1.12-branch)xorg-server-1.12.4-2-g78c77356c5d88d78d69b1a244c7e27cd85544842 Xf86_video_intel: (master)2.20.8-36-g8bfd31e9bb13bcb7f12e4147bec0da87b8e87dde Cairo: (master)797441093a8346003552e0cf89aef2a644ff53ab --- GPU Driver: ( this is the latest) Libva: commit a78128ac9a52b7567296e076c3cd9e5b7ea640ad Author: Jonathan Bian jonathan.b...@intel.com Date: Sun Sep 16 21:26:00 2012 -0700 Intel-driver: commit eb5f7f88fbd9085c3346a6b00698cef091e2ece2 Author: Gwenole Beauchesne gwenole.beauche...@intel.com Date: Wed Aug 29 18:37:25 2012 +0200 Thanks, Chao -Original Message- From: intel-gfx-bounces+haihao.xiang=intel@lists.freedesktop.org [mailto:intel-gfx-bounces+haihao.xiang=intel@lists.freedesktop.org] On Behalf Of Guilherme M. Schroeder Sent: Thursday, September 20, 2012 5:59 PM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] [regression] 3.6-rc6, gpu hang with vaapi Hi, I get a GPU hang every time i play an mkv using mplayer -vo vaapi with 3.6-rc6. With 3.5.4 no GPU hang at all. I'm using xf86-video-intel 2.20.8, xorg-server 1.12.4 and libva-1.1.0 on Intel(R) Sandybridge Mobile (GT2+). On dmesg, i915_error_state and Xorg.0.log: [ 105.822821] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 105.822825] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [ 111.871670] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 112.950746] [ cut here ] [ 112.950751] WARNING: at mm/page_alloc.c:2349 __alloc_pages_nodemask+0x87c/0x960() [ 112.950753] Hardware name: 4177CTO [ 112.950753] Modules linked in: fuse ip6table_filter ip6_tables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc snd_hda_codec_hdmi arc4 vhost_net tun macvtap macvlan snd_hda_codec_conexant iwldvm btusb joydev mac80211 kvm_intel iwlwifi i915 bluetooth intel_agp intel_gtt i2c_algo_bit drm_kms_helper cfg80211 drm thinkpad_acpi nvram rfkill snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 snd_timer e1000e i2c_i801 aes_generic ablk_helper snd cryptd iTCO_wdt iTCO_vendor_support soundcore lpc_ich i2c_core tpm_tis sdhci_pci sdhci mei mmc_core psmouse serio_raw kvm acpi_cpufreq battery video button thermal [ 112.950785] mperf mfd_core ac pcspkr evdev wmi tpm processor tpm_bios coretemp microcode autofs4 ext4 crc16 jbd2 mbcache sd_mod ahci ehci_hcd libahci libata scsi_mod usbcore usb_common [ 112.950795] Pid: 1461, comm: cp Not tainted 3.6.0-rc6-00052-gc46de22 #33 [ 112.950796] Call Trace: [ 112.950801] [81055bff] warn_slowpath_common+0x7f/0xc0 [ 112.950803] [81055c5a] warn_slowpath_null+0x1a/0x20 [ 112.950804] [81124ffc] __alloc_pages_nodemask+0x87c/0x960 [ 112.950807] [8115f6e0] alloc_pages_current+0xb0/0x120 [ 112.950809] [81120b8e] __get_free_pages+0xe/0x50 [ 112.950811] [81166329] kmalloc_order_trace+0x39/0xf0 [ 112.950812] [81168d17] __kmalloc+0x177/0x180 [ 112.950815] [811297cc] ? put_page+0x2c/0x40 [ 112.950818] [811988de] seq_read+0x10e/0x3b0 [ 112.950821] [81176a75] vfs_read+0xa5/0x180 [ 112.950822] [81176b9a] sys_read+0x4a/0xa0 [ 112.950825] [81486969] system_call_fastpath+0x16/0x1b [ 112.950826] ---[ end trace b5c3af991219a333 ]--- # cat /sys/kernel/debug/dri/0/i915_error_state cat: /sys/kernel/debug/dri/0/i915_error_state: Cannot allocate memory [ 115.163] [mi] EQ overflowing. Additional events will be discarded until existing events are processed. [ 115.163] [ 115.163] Backtrace: [ 115.174] 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x560366] [ 115.174] 1: /usr/bin/Xorg (mieqEnqueue+0x26b) [0x54161b] [ 115.174] 2: /usr/bin/Xorg (0x40+0x47f92) [0x447f92] [ 115.174] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fb83c986000+0x5f74) [0x7fb83c98bf74] [ 115.174] 4: /usr/bin/Xorg (0x40+0x6efd7) [0x46efd7] [ 115.174] 5: /usr/bin/Xorg (0x40+0x93370) [0x493370] [
