Re: [Intel-gfx] [PATCH 2/2] drm/i915/dp: check eDP display control capability registers
On Mon, Nov 18, 2013 at 05:38:18PM +0100, Daniel Vetter wrote: On Mon, Nov 18, 2013 at 5:31 PM, Thierry Reding thierry.red...@gmail.com wrote: Note that there's already a bit of abstraction for i2c over dp aux, but imo that's at the wrong level. At least reading through i915, gma500 and radeon code there's a lot more we could share with just a dp aux helper library (which then implements useful stuff on top of it). I have some difficulty envisioning how the helper code can work without some sort of driver-specific ops implementation. Currently the helpers only use a snapshot of the DPCD to extract information. Eventually we'll be bound to modify the DPCD, so some method of writing it back (or a subset of it) will be needed. Otherwise the scope of the helper library will be somewhat limited. Once we have the callbacks, the current helpers could be reworked to not use a buffer, but rather an AUX channel object and access the registers directly. If there are concerns about performance, it could possibly be implemented as a sort of cache, too. That would make it fast to query the status. I don't think it'll be worth the added complexity, though. Oh, my idea is that the dp aux driver callback would at the level of the intel_dp_aux_ch function in i915/intel_dp.c (gma500 and radeon have something very similar). That alone would allow us to share a considerable amount of code. Should have been a bit clearer, I've discussed this in a bit more detail with Alex many moons ago ... Yeah, that's similar to what I had in mind. I think we may need something slightly more complex, though. We want to support both AUX as well as I2C over AUX transactions, so we'll probably need to add a mode argument. I was thinking about adding a dp_aux_msg structure in order to keep the argument list to a reasonable length. Thierry pgpUFOw1z0LHR.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.crtc_clock (expected 108000, found 0)
Please boot with drm.debug=0xe added to your kernel cmdline, reproduce the issue and then attach the complete dmesg. Please make sure it contains everything from boot-up. Also _always_ cc relevant mailing lists when reporting an issue -Daniel On Tue, Nov 19, 2013 at 9:54 AM, Krzysztof Kolasa kkol...@winsoft.pl wrote: [ 35.464081] [ cut here ] [ 35.464127] WARNING: CPU: 1 PID: 1155 at drivers/gpu/drm/i915/intel_display.c:9262 check_crtc_state+0x289/0x360 [i915]() [ 35.464129] pipe state doesn't match! [ 35.464132] Modules linked in: pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) snd_hda_codec_si3054 snd_hda_codec_realtek joydev 8192cu(O) snd_hda_intel snd_hda_codec snd_hwdep snd_pcm usb_storage snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq psmouse serio_raw lpc_ich snd_timer snd_seq_device mac_hid i915 snd drm_kms_helper bnep drm rfcomm i2c_algo_bit soundcore bluetooth snd_page_alloc parport_pc video ppdev lp parport 8139too 8139cp [ 35.464176] CPU: 1 PID: 1155 Comm: Xorg Tainted: GW O 3.13.0-rc1-winsoft-pae #6 [ 35.464180] Hardware name: FUJITSU SIEMENS AMILO Pro Edition V3405 /AMILO Pro Edition V3405, BIOS R01-B0E 03/20/2007 [ 35.464183] f6eb1964 c15f6078 f893454c f6eb1994 c1041d24 f893e2ff [ 35.464192] f6eb19c0 0483 f893454c 242e f88e1549 f88e1549 f6818000 f681864c [ 35.464201] 0001 f6eb19ac c1041de3 0009 f6eb19a4 f893e2ff f6eb19c0 f6eb1c1c [ 35.464210] Call Trace: [ 35.464219] [c15f6078] dump_stack+0x41/0x52 [ 35.464227] [c1041d24] warn_slowpath_common+0x84/0xa0 [ 35.464258] [f88e1549] ? check_crtc_state+0x289/0x360 [i915] [ 35.464288] [f88e1549] ? check_crtc_state+0x289/0x360 [i915] [ 35.464293] [c1041de3] warn_slowpath_fmt+0x33/0x40 [ 35.464323] [f88e1549] check_crtc_state+0x289/0x360 [i915] [ 35.464359] [f88ec3e5] intel_modeset_check_state+0x55/0x90 [i915] [ 35.464389] [f88ec454] intel_set_mode+0x34/0x40 [i915] [ 35.464419] [f88ed28d] intel_get_load_detect_pipe+0x21d/0x300 [i915] [ 35.464458] [f8911c85] intel_tv_detect+0x125/0x230 [i915] [ 35.464466] [c111962b] ? shmem_recalc_inode+0x7b/0xb0 [ 35.464476] [f86ee0b0] drm_helper_probe_single_connector_modes+0x1d0/0x360 [drm_kms_helper] [ 35.464503] [f8752eec] ? drm_mode_object_find+0x6c/0xb0 [drm] [ 35.464525] [f8756371] drm_mode_getconnector+0x371/0x3a0 [drm] [ 35.464544] [f87488d8] drm_ioctl+0x488/0x530 [drm] [ 35.464552] [c10526b3] ? __set_current_blocked+0x33/0x50 [ 35.464573] [f8756000] ? drm_mode_getcrtc+0xc0/0xc0 [drm] [ 35.464590] [f8748450] ? drm_free_buffer+0x30/0x30 [drm] [ 35.464595] [c1162bd2] do_vfs_ioctl+0x72/0x2d0 [ 35.464601] [c1162ec7] SyS_ioctl+0x97/0xa0 [ 35.464606] [c10024df] ? sys_sigreturn+0x9f/0xb0 [ 35.464612] [c16070c1] sysenter_do_call+0x12/0x22 [ 35.464615] ---[ end trace 848bc934df119034 ]--- -- 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] kernel 3.11.6 general protection fault
Hi On Sunday 17 November 2013 21:05:46 Borislav Petkov wrote: On Sun, Nov 17, 2013 at 05:45:18PM +0100, MPhil. Emanoil Kotsev wrote: How - new libraries - more exhaustive algorythms - higher cpu usage etc. Some of the things M$ is doing on purpose to force you upgrade your hardware every 2-3years That would be too easy and machines would be dying left and right of overheating. Actually, sane hardware is much more robust than that and it throttles itself in case of critical temperature levels. And, IMHO your Dell Latitude D520 should be fine, in that respect. But we'll see. I was thinking the same - but started to despair :-) : I wanted to first compile the kernel with the debug option you mentioned, but while compiling it went to about 75°C. Yeah, that's still ok if we trust the output saying that 126°C is the critical temp. It would be interesting to see what this sensor says right before the machine locks up. This test is outstanding for a moment where I have more free time to reproduce and log everything I did something else yesterday evening before going to bed ~00:30 I closed the notebook cover just so that it would switch off the LCD display In the morning I opened up and found the notebook with blinking led lights http://www.dell.com/support/troubleshooting/us/en/19/KCS/KcsArticles/ArticleView?c=usl=ens=dhsdocid=DSN_DBECF64CFEDA449398CB9E859D4944A5 unfortunately I don't find the pattern in the link above the left one was on and the other two were blinking Arter shut down (keep power button pressed) and turning it on only the two leds (middle and right) were blinking, which according the link above means Configuring PCI bridges Replacing the system board. After waiting for about 1-2mins notebook starts normally - another link to heating issues. At the moment I have to do pretty much at all levels, so I can not test any further. This is just an update. I'll post again when more results are available. I'm thinking to open up and inspect from inside - perhaps somewhere the cooling system is clogged or something. regards ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Fwd: [PATCH] Watermark level workaround for i830
Hi Daniel,
did you get this? (See below)?
In the meantime, I also checked with video overlays, and the minimum
value of 6 is not yet quite optimal, higher values (lower watermarks)
seem to do even better. From the values I get, I also estimate a minimum
latency of about 1100 ns, the default value of 5000 is much too high for
the i830.
There are two alternative possibilities to fix this:
a) Include in the watermark structure not only a maximum value, but also
a minimum value and modify calculate_wm accordingly,
-and/or-
c) include a latency value in the watermark structure, setting it to
a lower value on i830.
What do you think?
Greetings,
Thomas
Original-Nachricht
Betreff: [PATCH] Watermark level workaround for i830
Datum: Mon, 18 Nov 2013 10:42:31 +0100
Von: Thomas Richter t...@math.tu-berlin.de
An: Daniel Vetter dan...@ffwll.ch
Kopie (CC): intel-gfx@lists.freedesktop.org
Hi Daniel, hi intel experts,
please find a patch attached concerning the watermark levels on the i830
chipsets.
I did a couple of experiments this morning and found that the watermark
on i830 may neither be
too small (i.e. the FW_BLC register values may not be too high) as
otherwise the FIFO runs try, but
for some strange reasons, the watermark may neither be too high (the
FW_BLC register must not
be too small) as otherwise the display flickers. Reasons for this are
unclear at this moment, though
the attached patch seems to remove flickering quite reliably on linear
and tiled displays.
What I should probably also report is that the watermark is set quite
too low (i.e. much too conservative)
on the R31. The computed values are 1 and 5 (for VGA and LVDS,
respectively), though the minimum
required levels are much higher, somewhere in the ballpark of 32.
Greetings,
Thomas
From f535e532f3279e43a7f20bc96d4e62b24a9af684 Mon Sep 17 00:00:00 2001
From: Thomas Richter t...@math.tu-berlin.de
Date: Mon, 18 Nov 2013 10:38:27 +0100
Subject: [PATCH 3/3] Watermark configuration workaround for i830 chipsets.
For unclear reasons, the watermark level on i830 and related
chipsets must not grow above 6 as otherwise display flickering
will occurr, specifically on panning.
Signed-off-by: Thomas Richter t...@math.tu-berlin.de
---
drivers/gpu/drm/i915/intel_pm.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 365545f..43c65f0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1648,6 +1648,21 @@ static void i9xx_update_wm(struct drm_crtc *unused_crtc)
I915_WRITE(FW_BLC_SELF, srwm 0x3f);
}
+ if (IS_I830(dev)) {
+ /* For unknown reasons, i830 chipsets run havok
+ * on panning if the watermark is below 6,
+ * thus adjust it accordingly.
+ */
+ if (planea_wm 6) {
+ planea_wm = 6;
+ DRM_DEBUG_KMS(i9xx plane A wm workaround enabled\n);
+ }
+ if (planeb_wm 6) {
+ planeb_wm = 6;
+ DRM_DEBUG_KMS(i9xx plane B wm workaround enabled\n);
+ }
+ }
+
DRM_DEBUG_KMS(Setting FIFO watermarks - A: %d, B: %d, C: %d, SR %d\n,
planea_wm, planeb_wm, cwm, srwm);
@@ -1692,6 +1707,16 @@ static void i830_update_wm(struct drm_crtc *unused_crtc)
i830_wm_info,
dev_priv-display.get_fifo_size(dev, 0),
4, latency_ns);
+
+ /* For unknown reasons, i830 chipsets run havok
+ * on panning if the watermark is below 6,
+ * thus adjust it accordingly.
+ */
+ if (planea_wm 6) {
+ planea_wm = 6;
+ DRM_DEBUG_KMS(i830 plane A wm workaround enabled\n);
+ }
+
fwater_lo = I915_READ(FW_BLC) ~0xfff;
fwater_lo |= (38) | planea_wm;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.crtc_clock (expected 108000, found 0)
On Tue, Nov 19, 2013 at 10:42 AM, Krzysztof Kolasa kkol...@winsoft.pl wrote: Ok dmesg ready and is attached to email. Should be fixed in latest drm-intel-fixes from http://cgit.freedesktop.org/~danvet/drm-intel/ The patches are for 3.13 but will get backported as soon as they land in upstream. -Daniel On 19.11.2013 10:15, Daniel Vetter wrote: Please boot with drm.debug=0xe added to your kernel cmdline, reproduce the issue and then attach the complete dmesg. Please make sure it contains everything from boot-up. Also _always_ cc relevant mailing lists when reporting an issue -Daniel On Tue, Nov 19, 2013 at 9:54 AM, Krzysztof Kolasa kkol...@winsoft.pl wrote: [ 35.464081] [ cut here ] [ 35.464127] WARNING: CPU: 1 PID: 1155 at drivers/gpu/drm/i915/intel_display.c:9262 check_crtc_state+0x289/0x360 [i915]() [ 35.464129] pipe state doesn't match! [ 35.464132] Modules linked in: pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) snd_hda_codec_si3054 snd_hda_codec_realtek joydev 8192cu(O) snd_hda_intel snd_hda_codec snd_hwdep snd_pcm usb_storage snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq psmouse serio_raw lpc_ich snd_timer snd_seq_device mac_hid i915 snd drm_kms_helper bnep drm rfcomm i2c_algo_bit soundcore bluetooth snd_page_alloc parport_pc video ppdev lp parport 8139too 8139cp [ 35.464176] CPU: 1 PID: 1155 Comm: Xorg Tainted: GW O 3.13.0-rc1-winsoft-pae #6 [ 35.464180] Hardware name: FUJITSU SIEMENS AMILO Pro Edition V3405 /AMILO Pro Edition V3405, BIOS R01-B0E 03/20/2007 [ 35.464183] f6eb1964 c15f6078 f893454c f6eb1994 c1041d24 f893e2ff [ 35.464192] f6eb19c0 0483 f893454c 242e f88e1549 f88e1549 f6818000 f681864c [ 35.464201] 0001 f6eb19ac c1041de3 0009 f6eb19a4 f893e2ff f6eb19c0 f6eb1c1c [ 35.464210] Call Trace: [ 35.464219] [c15f6078] dump_stack+0x41/0x52 [ 35.464227] [c1041d24] warn_slowpath_common+0x84/0xa0 [ 35.464258] [f88e1549] ? check_crtc_state+0x289/0x360 [i915] [ 35.464288] [f88e1549] ? check_crtc_state+0x289/0x360 [i915] [ 35.464293] [c1041de3] warn_slowpath_fmt+0x33/0x40 [ 35.464323] [f88e1549] check_crtc_state+0x289/0x360 [i915] [ 35.464359] [f88ec3e5] intel_modeset_check_state+0x55/0x90 [i915] [ 35.464389] [f88ec454] intel_set_mode+0x34/0x40 [i915] [ 35.464419] [f88ed28d] intel_get_load_detect_pipe+0x21d/0x300 [i915] [ 35.464458] [f8911c85] intel_tv_detect+0x125/0x230 [i915] [ 35.464466] [c111962b] ? shmem_recalc_inode+0x7b/0xb0 [ 35.464476] [f86ee0b0] drm_helper_probe_single_connector_modes+0x1d0/0x360 [drm_kms_helper] [ 35.464503] [f8752eec] ? drm_mode_object_find+0x6c/0xb0 [drm] [ 35.464525] [f8756371] drm_mode_getconnector+0x371/0x3a0 [drm] [ 35.464544] [f87488d8] drm_ioctl+0x488/0x530 [drm] [ 35.464552] [c10526b3] ? __set_current_blocked+0x33/0x50 [ 35.464573] [f8756000] ? drm_mode_getcrtc+0xc0/0xc0 [drm] [ 35.464590] [f8748450] ? drm_free_buffer+0x30/0x30 [drm] [ 35.464595] [c1162bd2] do_vfs_ioctl+0x72/0x2d0 [ 35.464601] [c1162ec7] SyS_ioctl+0x97/0xa0 [ 35.464606] [c10024df] ? sys_sigreturn+0x9f/0xb0 [ 35.464612] [c16070c1] sysenter_do_call+0x12/0x22 [ 35.464615] ---[ end trace 848bc934df119034 ]--- -- 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] Watermark level workaround for i830
On Tue, Nov 19, 2013 at 10:55 AM, Thomas Richter t...@math.tu-berlin.de wrote: In the meantime, I also checked with video overlays, and the minimum value of 6 is not yet quite optimal, higher values (lower watermarks) seem to do even better. From the values I get, I also estimate a minimum latency of about 1100 ns, the default value of 5000 is much too high for the i830. There are two alternative possibilities to fix this: a) Include in the watermark structure not only a maximum value, but also a minimum value and modify calculate_wm accordingly, I think this is what we need - Bspec explicitly mentions that setting the watermark so that the fifo could overrun with the given burst length is a bad idea. Atm we set the brust length to 8, so my standing bet is that this is the limit where things start to get fully stable. I've started to work on patches for this last w/e but got distracted a bit with my real job, hence the silence. -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 driver gpu hung kernel 3.11
Hi Bruno, Thanks for the response. I have subscribed to the intel-gfx list. I didn't post the error_state file since it huge. I was trying to play Myst Online using wine-1.3.24. I get started and start moving my avatar fairly quickly I get the error. I have built the latest X, mesa etc from the git repo and loaded the latest kernel but still have the problem, though now my screen doesn't lose horizontal sync like it used to before I uppgraded X etc. Below is a lspci of my laptop. 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 3 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller (rev 02) 00:1f.3 SMBus: Intel Corporation N10/ICH 7 Family SMBus Controller (rev 02) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02) 05:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller 05:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 19) 05:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 01) 05:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 0a) 05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10) On 11/18/2013 12:41 PM, Bruno Prémont wrote: Hi Stephen, You may want to CC intel-gfx@lists.freedesktop.org for i915 issues (even if you are not subscribed and you mail will wait for a moderator to let it go through). In case of intel GPU hangs you should at least include /sys/kernel/debug/dri/0/i915_error_state, probably submitting as a bug report on bugs.freedesktop.org due to its size. If you have any indication on what triggers the hang, please add! Bruno On Sun, 17 November 2013 Stephen Clarksclar...@earthlink.net wrote: Hi List, I am getting this in kernel 3.11 x86_64 Nov 17 18:56:19 joker4 kernel: [drm:i915_hangcheck_elapsed] *ERROR* stuck on render ring Nov 17 18:56:19 joker4 kernel: [drm] capturing error event; look for more information in /sys/kernel/debug/dri/0/i915_error_state Nov 17 18:56:19 joker4 kernel: swapper/1: page allocation failure: order:6, mode:0x200020 Nov 17 18:56:19 joker4 kernel: CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.11.6-1.el6.elrepo.x86_64 #1 Nov 17 18:56:19 joker4 kernel: Hardware name: To Be Filled By O.E.M. Z96F/Z96F, BIOS 080012 08/29/2006 Nov 17 18:56:19 joker4 kernel: 0006 8800b73038e0 815f7f89 0010 Nov 17 18:56:19 joker4 kernel: 00200020 8800b7303970 8114243d 8800b778ab28 Nov 17 18:56:19 joker4 kernel: 0031 8800b7789000 00060002 Nov 17 18:56:19 joker4 kernel: Call Trace: Nov 17 18:56:19 joker4 kernel:IRQ [815f7f89] dump_stack+0x49/0x60 Nov 17 18:56:19 joker4 kernel: [8114243d] warn_alloc_failed+0xfd/0x160 Nov 17 18:56:19 joker4 kernel: [8114e98c] ? wakeup_kswapd+0x10c/0x140 Nov 17 18:56:19 joker4 kernel: [811455ae] __alloc_pages_slowpath+0x4ae/0x7c0 Nov 17 18:56:19 joker4 kernel: [81142d9d] ? get_page_from_freelist+0x2dd/0x710 Nov 17 18:56:19 joker4 kernel: [81145bce] __alloc_pages_nodemask+0x30e/0x330 Nov 17 18:56:19 joker4 kernel: [8118c437] kmem_getpages+0x67/0x1e0 Nov 17 18:56:19 joker4 kernel: [8118dea9] fallback_alloc+0x189/0x270 Nov 17 18:56:19 joker4 kernel: [8118dc55] cache_alloc_node+0x95/0x160 Nov 17 18:56:19 joker4 kernel: [8118e9b7] __kmalloc+0x177/0x2c0 Nov 17 18:56:19 joker4 kernel: [a0044a29] ? i915_capture_error_state+0x379/0x720 [i915] Nov 17 18:56:19 joker4 kernel: [a0044a29] i915_capture_error_state+0x379/0x720 [i915]
Re: [Intel-gfx] [PATCH 3/9] drm/i915: Use frame counter for intel_wait_for_vblank() on CTG
On Mon, Nov 18, 2013 at 06:32:32PM -0800, Rodrigo Vivi wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Use the same wait_for_vblank code for CTG that we use for ILK+. Also fix the name of the frame counter register while at it. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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 2/9] drm/i915: Fix gen3/4 vblank counter wraparound
On Mon, Nov 18, 2013 at 06:32:31PM -0800, Rodrigo Vivi wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com When the hardware frame counter reads 0xff and we're already past vblank start, we'd return 0x100 as the vblank counter value. Once we'd cross into the next frame's active portion, the vblank counter would wrap to 0. So we're reporting two different vblank counter values for the same frame. Fix the problem by masking the cooked value by 0xff to make sure the counter wraps already after vblank start. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com Already applied: edc08d0a40f7ddab6bf7249e59ecf692d36c7192 -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 5/9] drm/i915: print object bindings in debugfs
On Mon, Nov 18, 2013 at 06:32:34PM -0800, Rodrigo Vivi wrote: From: Daniel Vetter daniel.vet...@ffwll.ch This is useful when we only have aliasing ppgtt and want to figure out what exactly is accesssible and what not. Paulo can somehow overwrite the fbcon framebuffer with the blitter on his hsw machine ... v2: Actually make it compile. Cc: Paulo Zanoni przan...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com This is still too ugly. (bindings: ) (bindings: g) (bindings: pp) (bindings: gpp) -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 1/2] drm/i915: Fix fbc + rc6 combination on SNB
On Mon, Nov 18, 2013 at 06:08:15PM -0800, Rodrigo Vivi wrote:
I'm just on going with another -collector update and since this patch
fixes a bug I think it would be a good one to include.
But since it was bikeshedded it is better to ask Ville and Chris if
their comments was a NAck or I can consider to get for -collector.
My FBC series makes this obsolete. I think I have a few more updates to
that series that I didn't post yet. I'll try to get those out today.
And I also have a crc based igt for this in the works.
Thanks
On Sat, Nov 2, 2013 at 9:10 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Fri, Nov 01, 2013 at 05:02:52PM -0700, Ben Widawsky wrote:
On Sandybridge we must set the PPGTT Render Target Base Address Valid
for FBC bit as noted in the programming guide. We did this at clock
gating init. Thisbit is not saved and restored with RC6 power context,
so the resetting it at ring flush should fix that.
The effect of not doing this should be corruption, and not a hang - as
has so often been the case.
Note that we should actually clear this bit as well when not blitting to
the scanout (using the blitter for other things), or else all operations
Cc: Stéphane Marchesin marc...@chromium.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/intel_pm.c | 2 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 25 +
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index ca9a778..67f460b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -193,8 +193,6 @@ static void sandybridge_blit_fbc_update(struct
drm_device *dev)
/* Make sure blitter notifies FBC of writes */
gen6_gt_force_wake_get(dev_priv);
blt_ecoskpd = I915_READ(GEN6_BLITTER_ECOSKPD);
- blt_ecoskpd |= GEN6_BLITTER_FBC_NOTIFY
- GEN6_BLITTER_LOCK_SHIFT;
I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
blt_ecoskpd |= GEN6_BLITTER_FBC_NOTIFY;
I915_WRITE(GEN6_BLITTER_ECOSKPD, blt_ecoskpd);
Why leave the other FBC_NOTIFY frobbing in place? Since you don't set
the mask bit anymore the rest isn't guaranteed to do anything.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2dec134..ddd7681 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -278,6 +278,28 @@ gen7_render_ring_cs_stall_wa(struct intel_ring_buffer
*ring)
return 0;
}
+static int gen6_ring_fbc_flush(struct intel_ring_buffer *ring)
+{
+ int ret;
+
+ if (!ring-fbc_dirty)
+ return 0;
+
+ ret = intel_ring_begin(ring, 4);
+ if (ret)
+ return ret;
+
+ intel_ring_emit(ring, MI_NOOP);
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, GEN6_BLITTER_ECOSKPD);
+ intel_ring_emit(ring,
+ _MASKED_BIT_ENABLE(GEN6_BLITTER_FBC_NOTIFY));
+ intel_ring_advance(ring);
+
+ ring-fbc_dirty = false;
+ return 0;
+}
+
static int gen7_ring_fbc_flush(struct intel_ring_buffer *ring, u32 value)
{
int ret;
@@ -1712,6 +1734,9 @@ static int gen6_ring_flush(struct intel_ring_buffer
*ring,
intel_ring_emit(ring, MI_NOOP);
intel_ring_advance(ring);
+ if (IS_GEN6(dev) flush)
+ return gen6_ring_fbc_flush(ring);
+
What Chris said about doing this before the batch is dispatched.
Afer a bit of thought I think the following logic would work nicely:
execbuffer() {
ring-new_fbc_obj = NULL;
for_each_obj() {
if (is_crtc_fb(obj) obj.write_domains)
ring-new_fbc_obj = obj;
if (gen = 7) {
if (ring-new_fbc_obj)
ring-fbc_dirty = true;
} else {
if (ring-new_fb_obj != ring-fbc_obj) {
ring-fbc_obj = ring-new_fbc_obj;
ring-fbc_dirty = true;
}
}
invalidate() {
if (gen 7 ring-fbc_dirty) {
if (ring-fbc_obj)
enable_tracking;
else
disable_tracking;
}
}
dispatch()
flush() {
if (gen = 7 ring-fbc_dirty)
fbc_nuke();
ring-fbc_dirty = false;
}
}
I think that same logic would work for both blitter and render. The
difference between the two is that for render we also need to update
the address, for blitter we just need to set the notify bit.
Also since we could update the render tracking for every
Re: [Intel-gfx] [PATCH] drm/i915: Replicate BIOS eDP bpp clamping hack for hsw
On Mon, Nov 18, 2013 at 07:38:16AM +0100, Daniel Vetter wrote:
Haswell's DDI encoders have their own -get_config callback and in
commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
Author: Jani Nikula jani.nik...@intel.com
Date: Mon Oct 21 10:52:07 2013 +0300
drm/i915/dp: workaround BIOS eDP bpp clamping issue
we've forgotten to replicate this hack. So let's do it that.
Note for backporters: The above commit and all it's depencies need to
be backported first.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049
Cc: sta...@vger.kernel.org
Tested-by: Gökçen Eraslan gokcen.eras...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Although I might suggest moving the hack into a small function of its
own and calling it from both ddi and dp code.
---
drivers/gpu/drm/i915/intel_ddi.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 1591576a6101..330077bcd0bd 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1406,6 +1406,26 @@ void intel_ddi_get_config(struct intel_encoder
*encoder,
default:
break;
}
+
+ if (encoder-type == INTEL_OUTPUT_EDP dev_priv-vbt.edp_bpp
+ pipe_config-pipe_bpp dev_priv-vbt.edp_bpp) {
+ /*
+ * This is a big fat ugly hack.
+ *
+ * Some machines in UEFI boot mode provide us a VBT that has 18
+ * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
+ * unknown we fail to light up. Yet the same BIOS boots up with
+ * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
+ * max, not what it tells us to use.
+ *
+ * Note: This will still be broken if the eDP panel is not lit
+ * up by the BIOS, and thus we can't get the mode at module
+ * load.
+ */
+ DRM_DEBUG_KMS(pipe has %d bpp for eDP panel, overriding
BIOS-provided max %d bpp\n,
+ pipe_config-pipe_bpp, dev_priv-vbt.edp_bpp);
+ dev_priv-vbt.edp_bpp = pipe_config-pipe_bpp;
+ }
}
static void intel_ddi_destroy(struct drm_encoder *encoder)
--
1.8.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Replicate BIOS eDP bpp clamping hack for hsw
On Tue, Nov 19, 2013 at 05:51:54PM +0200, Ville Syrjälä wrote:
On Mon, Nov 18, 2013 at 07:38:16AM +0100, Daniel Vetter wrote:
Haswell's DDI encoders have their own -get_config callback and in
commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
Author: Jani Nikula jani.nik...@intel.com
Date: Mon Oct 21 10:52:07 2013 +0300
drm/i915/dp: workaround BIOS eDP bpp clamping issue
we've forgotten to replicate this hack. So let's do it that.
Note for backporters: The above commit and all it's depencies need to
be backported first.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049
Cc: sta...@vger.kernel.org
Tested-by: Gökçen Eraslan gokcen.eras...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Thanks for the review, merged to -fixes.
Although I might suggest moving the hack into a small function of its
own and calling it from both ddi and dp code.
I've considered this, but then 90% of the code is the comment explaining
what's going on, so I've figured it's better to duplicate this. If we grow
more edp vbt hacks in -get_config we can reconsider. But I hope not,
since atm we have no chance to light up the panel if the bios didn't do so
already :(
-Daniel
---
drivers/gpu/drm/i915/intel_ddi.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 1591576a6101..330077bcd0bd 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1406,6 +1406,26 @@ void intel_ddi_get_config(struct intel_encoder
*encoder,
default:
break;
}
+
+ if (encoder-type == INTEL_OUTPUT_EDP dev_priv-vbt.edp_bpp
+ pipe_config-pipe_bpp dev_priv-vbt.edp_bpp) {
+ /*
+* This is a big fat ugly hack.
+*
+* Some machines in UEFI boot mode provide us a VBT that has 18
+* bpp and 1.62 GHz link bandwidth for eDP, which for reasons
+* unknown we fail to light up. Yet the same BIOS boots up with
+* 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
+* max, not what it tells us to use.
+*
+* Note: This will still be broken if the eDP panel is not lit
+* up by the BIOS, and thus we can't get the mode at module
+* load.
+*/
+ DRM_DEBUG_KMS(pipe has %d bpp for eDP panel, overriding
BIOS-provided max %d bpp\n,
+ pipe_config-pipe_bpp, dev_priv-vbt.edp_bpp);
+ dev_priv-vbt.edp_bpp = pipe_config-pipe_bpp;
+ }
}
static void intel_ddi_destroy(struct drm_encoder *encoder)
--
1.8.4.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
[Intel-gfx] [PATCH] Added a lower limit for the watermark setting
Hi Daniel, dear intel experts,
please find a patch attached that finally addresses the display flicker
on i830 chipsets. This
patch adds a lower watermark setting in intel_watermark_params{}, but
keeps it zero for
all but the i830 chipsets. The necessary new defines are in i915_reg.h.
Greetings,
Thomas
From 916d8354b2134d587b946fa88c66c3d098d38df4 Mon Sep 17 00:00:00 2001
From: Thomas Richter t...@math.tu-berlin.de
Date: Tue, 19 Nov 2013 17:09:45 +0100
Subject: [PATCH 3/3] Added a lower limit for the watermark setting.
This patch adds a minimum value for the watermark setting, in addition
to the already existing upper limit. The lower limit is necessary on
i830 chipsets as otherwise display flickering may result, especially
on panning. While the flicker itself is caused by the FIFO running
dry. Interestingly, an overrunning FIFO may also cause a hickup in
the chipset which results in a pipeline stall with the very same
effects.
Lower limits for all other chipsets are zero to remain consistent
with the currently active code.
Signed-off-by: Thomas Richter t...@math.tu-berlin.de
---
drivers/gpu/drm/i915/i915_reg.h | 16
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 24
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 849e595..c144957 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3361,24 +3361,32 @@
#define I915_FIFO_SIZE 95
#define I855GM_FIFO_SIZE 127 /* In cachelines */
#define I830_FIFO_SIZE 95
+#define I830_MIN_WM 8 /* instabilities if below this point */
+#define VALLEYVIEW_MIN_WM 0
#define VALLEYVIEW_MAX_WM 0xff
+#define G4X_MIN_WM 0
#define G4X_MAX_WM 0x3f
+#define I915_MIN_WM 0
#define I915_MAX_WM 0x3f
#define PINEVIEW_DISPLAY_FIFO 512 /* in 64byte unit */
#define PINEVIEW_FIFO_LINE_SIZE 64
+#define PINEVIEW_MIN_WM0
#define PINEVIEW_MAX_WM 0x1ff
#define PINEVIEW_DFT_WM 0x3f
#define PINEVIEW_DFT_HPLLOFF_WM 0
#define PINEVIEW_GUARD_WM 10
#define PINEVIEW_CURSOR_FIFO 64
+#define PINEVIEW_CURSOR_MIN_WM 0
#define PINEVIEW_CURSOR_MAX_WM 0x3f
#define PINEVIEW_CURSOR_DFT_WM 0
#define PINEVIEW_CURSOR_GUARD_WM 5
#define VALLEYVIEW_CURSOR_MAX_WM 64
+#define VALLEYVIEW_CURSOR_MIN_WM 0
#define I965_CURSOR_FIFO 64
+#define I965_CURSOR_MIN_WM 0
#define I965_CURSOR_MAX_WM 32
#define I965_CURSOR_DFT_WM 8
@@ -3424,16 +3432,20 @@
/* define the fifo size on Ironlake */
#define ILK_DISPLAY_FIFO 128
+#define ILK_DISPLAY_MINWM 0
#define ILK_DISPLAY_MAXWM 64
#define ILK_DISPLAY_DFTWM 8
#define ILK_CURSOR_FIFO 32
+#define ILK_CURSOR_MINWM0
#define ILK_CURSOR_MAXWM 16
#define ILK_CURSOR_DFTWM 8
#define ILK_DISPLAY_SR_FIFO 512
+#define ILK_DISPLAY_MIN_SRWM 0
#define ILK_DISPLAY_MAX_SRWM 0x1ff
#define ILK_DISPLAY_DFT_SRWM 0x3f
#define ILK_CURSOR_SR_FIFO 64
+#define ILK_CURSOR_MIN_SRWM 0
#define ILK_CURSOR_MAX_SRWM 0x3f
#define ILK_CURSOR_DFT_SRWM 8
@@ -3441,16 +3453,20 @@
/* define the WM info on Sandybridge */
#define SNB_DISPLAY_FIFO 128
+#define SNB_DISPLAY_MINWM 0
#define SNB_DISPLAY_MAXWM 0x7f /* bit 16:22 */
#define SNB_DISPLAY_DFTWM 8
#define SNB_CURSOR_FIFO 32
+#define SNB_CURSOR_MINWM 0
#define SNB_CURSOR_MAXWM 0x1f /* bit 4:0 */
#define SNB_CURSOR_DFTWM 8
#define SNB_DISPLAY_SR_FIFO 512
+#define SNB_DISPLAY_MIN_SRWM 0
#define SNB_DISPLAY_MAX_SRWM 0x1ff /* bit 16:8 */
#define SNB_DISPLAY_DFT_SRWM 0x3f
#define SNB_CURSOR_SR_FIFO 64
+#define SNB_CURSOR_MIN_SRWM 0
#define SNB_CURSOR_MAX_SRWM 0x3f /* bit 5:0 */
#define SNB_CURSOR_DFT_SRWM 8
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8e133de..9400b1a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -418,6 +418,7 @@ struct intel_plane {
struct intel_watermark_params {
unsigned long fifo_size;
+ unsigned long min_wm;
unsigned long max_wm;
unsigned long default_wm;
unsigned long guard_size;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9c8b374..47f6fc8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -868,6 +868,7 @@ static int i830_get_fifo_size(struct drm_device *dev, int plane)
/* Pineview has different values for various configs */
static const struct intel_watermark_params pineview_display_wm = {
PINEVIEW_DISPLAY_FIFO,
+ PINEVIEW_MIN_WM,
PINEVIEW_MAX_WM,
PINEVIEW_DFT_WM,
PINEVIEW_GUARD_WM,
@@ -875,6 +876,7 @@ static const struct intel_watermark_params pineview_display_wm = {
};
static const struct intel_watermark_params pineview_display_hplloff_wm = {
PINEVIEW_DISPLAY_FIFO,
+ PINEVIEW_MIN_WM,
PINEVIEW_MAX_WM,
PINEVIEW_DFT_HPLLOFF_WM,
PINEVIEW_GUARD_WM,
@@ -882,6 +884,7 @@ static const struct intel_watermark_params pineview_display_hplloff_wm = {
};
static const struct
Re: [Intel-gfx] [PATCH 3/9] drm/i915: Use frame counter for intel_wait_for_vblank() on CTG
On Tue, Nov 19, 2013 at 01:46:55PM +, Chris Wilson wrote: On Mon, Nov 18, 2013 at 06:32:32PM -0800, Rodrigo Vivi wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Use the same wait_for_vblank code for CTG that we use for ILK+. Also fix the name of the frame counter register while at it. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Already merged as 57e22f4add51b, apparently from a previous -collector round (sinc it has your sob on it). Rebase gone wrong? -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] Added a lower limit for the watermark setting
On Tue, Nov 19, 2013 at 05:15:09PM +0100, Thomas Richter wrote:
Hi Daniel, dear intel experts,
please find a patch attached that finally addresses the display
flicker on i830 chipsets. This
patch adds a lower watermark setting in intel_watermark_params{},
but keeps it zero for
all but the i830 chipsets. The necessary new defines are in i915_reg.h.
I think we ned to split out the gen2/3 single/dual pipe watermark code a
bit better from everything else. A bugfix for i830M shouldn't really
affect snb ;-)
I've pushed out my current (and rather broken) wip branch with my idea on
the take to
http://cgit.freedesktop.org/~danvet/drm/log/?h=for-thomas
Cheers, Daniel
Greetings,
Thomas
From 916d8354b2134d587b946fa88c66c3d098d38df4 Mon Sep 17 00:00:00 2001
From: Thomas Richter t...@math.tu-berlin.de
Date: Tue, 19 Nov 2013 17:09:45 +0100
Subject: [PATCH 3/3] Added a lower limit for the watermark setting.
This patch adds a minimum value for the watermark setting, in addition
to the already existing upper limit. The lower limit is necessary on
i830 chipsets as otherwise display flickering may result, especially
on panning. While the flicker itself is caused by the FIFO running
dry. Interestingly, an overrunning FIFO may also cause a hickup in
the chipset which results in a pipeline stall with the very same
effects.
Lower limits for all other chipsets are zero to remain consistent
with the currently active code.
Signed-off-by: Thomas Richter t...@math.tu-berlin.de
---
drivers/gpu/drm/i915/i915_reg.h | 16
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 24
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 849e595..c144957 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3361,24 +3361,32 @@
#define I915_FIFO_SIZE 95
#define I855GM_FIFO_SIZE 127 /* In cachelines */
#define I830_FIFO_SIZE 95
+#define I830_MIN_WM 8 /* instabilities if below this point */
+#define VALLEYVIEW_MIN_WM0
#define VALLEYVIEW_MAX_WM0xff
+#define G4X_MIN_WM 0
#define G4X_MAX_WM 0x3f
+#define I915_MIN_WM 0
#define I915_MAX_WM 0x3f
#define PINEVIEW_DISPLAY_FIFO512 /* in 64byte unit */
#define PINEVIEW_FIFO_LINE_SIZE 64
+#define PINEVIEW_MIN_WM0
#define PINEVIEW_MAX_WM 0x1ff
#define PINEVIEW_DFT_WM 0x3f
#define PINEVIEW_DFT_HPLLOFF_WM 0
#define PINEVIEW_GUARD_WM10
#define PINEVIEW_CURSOR_FIFO 64
+#define PINEVIEW_CURSOR_MIN_WM 0
#define PINEVIEW_CURSOR_MAX_WM 0x3f
#define PINEVIEW_CURSOR_DFT_WM 0
#define PINEVIEW_CURSOR_GUARD_WM 5
#define VALLEYVIEW_CURSOR_MAX_WM 64
+#define VALLEYVIEW_CURSOR_MIN_WM 0
#define I965_CURSOR_FIFO 64
+#define I965_CURSOR_MIN_WM 0
#define I965_CURSOR_MAX_WM 32
#define I965_CURSOR_DFT_WM 8
@@ -3424,16 +3432,20 @@
/* define the fifo size on Ironlake */
#define ILK_DISPLAY_FIFO 128
+#define ILK_DISPLAY_MINWM0
#define ILK_DISPLAY_MAXWM64
#define ILK_DISPLAY_DFTWM8
#define ILK_CURSOR_FIFO 32
+#define ILK_CURSOR_MINWM0
#define ILK_CURSOR_MAXWM 16
#define ILK_CURSOR_DFTWM 8
#define ILK_DISPLAY_SR_FIFO 512
+#define ILK_DISPLAY_MIN_SRWM 0
#define ILK_DISPLAY_MAX_SRWM 0x1ff
#define ILK_DISPLAY_DFT_SRWM 0x3f
#define ILK_CURSOR_SR_FIFO 64
+#define ILK_CURSOR_MIN_SRWM 0
#define ILK_CURSOR_MAX_SRWM 0x3f
#define ILK_CURSOR_DFT_SRWM 8
@@ -3441,16 +3453,20 @@
/* define the WM info on Sandybridge */
#define SNB_DISPLAY_FIFO 128
+#define SNB_DISPLAY_MINWM0
#define SNB_DISPLAY_MAXWM0x7f/* bit 16:22 */
#define SNB_DISPLAY_DFTWM8
#define SNB_CURSOR_FIFO 32
+#define SNB_CURSOR_MINWM 0
#define SNB_CURSOR_MAXWM 0x1f/* bit 4:0 */
#define SNB_CURSOR_DFTWM 8
#define SNB_DISPLAY_SR_FIFO 512
+#define SNB_DISPLAY_MIN_SRWM 0
#define SNB_DISPLAY_MAX_SRWM 0x1ff /* bit 16:8 */
#define SNB_DISPLAY_DFT_SRWM 0x3f
#define SNB_CURSOR_SR_FIFO 64
+#define SNB_CURSOR_MIN_SRWM 0
#define SNB_CURSOR_MAX_SRWM 0x3f/* bit 5:0 */
#define SNB_CURSOR_DFT_SRWM 8
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 8e133de..9400b1a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -418,6 +418,7 @@ struct intel_plane {
struct intel_watermark_params {
unsigned long fifo_size;
+ unsigned long min_wm;
unsigned long max_wm;
unsigned long default_wm;
unsigned long guard_size;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9c8b374..47f6fc8 100644
---
Re: [Intel-gfx] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.crtc_clock (expected 108000, found 0)
On 19.11.2013 11:22, Daniel Vetter wrote: On Tue, Nov 19, 2013 at 10:42 AM, Krzysztof Kolasa kkol...@winsoft.pl wrote: Ok dmesg ready and is attached to email. Should be fixed in latest drm-intel-fixes from http://cgit.freedesktop.org/~danvet/drm-intel/ The patches are for 3.13 but will get backported as soon as they land in upstream. -Daniel Ok latest patches fix this error Thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] drm-intel-collector - update
On Mon, Nov 18, 2013 at 7:28 PM, Ausmus, James james.aus...@intel.com wrote: On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: This is another drm-intel-collector updated notice: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the update list in order for better reviewers assignment: Patch drm/i915: Asynchronously perform the set-base for a simple modeset - Reviewed by me. Patch drm/i915: Fix gen3/4 vblank counter wraparound - Reviewer: Patch drm/i915: Use frame counter for intel_wait_for_vblank() on CTG - Reviewer: Patch drm/i915: Do hw quiescing first during unload - Reviewer: Patch drm/i915: print object bindings in debugfs - Reviewer: Patch drm/i915/vlv: enable HDMI audio for Valleyview2 - Reviewer: Patch drm/i915: Hold pc8 lock around toggling pc8.gpu_idle - Reviewed by Paulo Patch drm/i915: Do not enable package C8 on unsupported hardware - Reviewed by Paulo Patch drm/i915: Enable pipe gamma for sprites - Reviewer: Overall Process: drm-intel-collector - review request 1. Daniel pushs drm-intel-testing (every 2 weeks) 2. I rebase drm-intel-collector onto drm-intel-testing 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you should be assigned on a particular patch please don't get mad just tell you wont review or volunteer someone else. 4. I resubmit remaining patches for review without picking any new (drm-intel-collector - review request) drm-intel-collector - updated 5. One week later I collect all simple (1-2) patches that wasn't yet reviewed and not queued by Daniel from one testing update until another. 6. Request automated QA's PRTS automated i-g-t tests comparing drm-intel-testing x drm-intel-collector 7. If tests are ok I send the update notification or the patches as a series to intel-gfx mailing list for better tracking and to be reviewed. (drm-intel-collector - updated) 8. Let me know volunteers for review new patches and also let me know if I've picked any patch that I shouldn't. There are some reasons that some patches can be left behind: 1. Your patch didn't applied cleanly and I couldn't easily solve the conflicts. 2. Kernel didn't compiled with your patch. 3. I simply missed it. If you believe this is the case please warn me. Please help me to get these patches reviewed and queued by Daniel. Also, please let me know if you have further ideas how to improve this process. Thanks in advance, Rodrigo. Chris Wilson (4): drm/i915: Asynchronously perform the set-base for a simple modeset drm/i915: Do hw quiescing first during unload drm/i915: Hold pc8 lock around toggling pc8.gpu_idle drm/i915: Do not enable package C8 on unsupported hardware Daniel Vetter (1): drm/i915: print object bindings in debugfs Mengdong Lin (1): drm/i915/vlv: enable HDMI audio for Valleyview2 A v4 of this patch was already merged in with a slightly renamed subject: 9ca2fe731b3f12afbc97cf0050dfa4184bd2234c drm/i915/vlv: enable HDA display audio for Valleyview2 Thank you for the warn. I'll remove it. -James Ville Syrjälä (3): drm/i915: Fix gen3/4 vblank counter wraparound drm/i915: Use frame counter for intel_wait_for_vblank() on CTG drm/i915: Enable pipe gamma for sprites drivers/gpu/drm/i915/i915_debugfs.c | 6 drivers/gpu/drm/i915/i915_dma.c | 10 +++--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 20 ++- drivers/gpu/drm/i915/intel_display.c | 65 drivers/gpu/drm/i915/intel_sprite.c | 18 ++ 7 files changed, 103 insertions(+), 19 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915: print object bindings in debugfs
On Tue, Nov 19, 2013 at 5:52 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Mon, Nov 18, 2013 at 06:32:34PM -0800, Rodrigo Vivi wrote: From: Daniel Vetter daniel.vet...@ffwll.ch This is useful when we only have aliasing ppgtt and want to figure out what exactly is accesssible and what not. Paulo can somehow overwrite the fbcon framebuffer with the blitter on his hsw machine ... v2: Actually make it compile. Cc: Paulo Zanoni przan...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com This is still too ugly. at least should be the opposite pp before g and complemented with a tt in the end. (bindings: ) (bindings: g) (bindings: pp) (bindings: gpp) -Chris But what are all real possible options? nothing, gtt or ppgtt? -- Chris Wilson, Intel Open Source Technology Centre -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 9/9] drm/i915: Enable pipe gamma for sprites
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com We send the primary and cursor plane data through the gamma unit. In order to get matching output from sprites, also send the sprite data through the gamma unit. In the future we should add some properties to control this explicitly, and also add properties for the per-sprite gamma ramps what have you, but for now this seems like a reasonable thing to do. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com --- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_sprite.c | 18 ++ 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 8f4916d..7b454d2 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3745,7 +3745,7 @@ #define _SPACNTR (VLV_DISPLAY_BASE + 0x72180) #define SP_ENABLE(131) -#define SP_GEAMMA_ENABLE (130) +#define SP_GAMMA_ENABLE (130) #define SP_PIXFORMAT_MASK(0xf26) #define SP_FORMAT_YUV422 (026) #define SP_FORMAT_BGR565 (526) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 8afaad6..cb7ffd3 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -104,6 +104,12 @@ vlv_update_plane(struct drm_plane *dplane, struct drm_crtc *crtc, break; } + /* +* Enable gamma to match primary/cursor plane behaviour. +* FIXME should be user controllable via propertiesa. +*/ + sprctl |= SP_GAMMA_ENABLE; + if (obj-tiling_mode != I915_TILING_NONE) sprctl |= SP_TILED; @@ -257,6 +263,12 @@ ivb_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, BUG(); } + /* +* Enable gamma to match primary/cursor plane behaviour. +* FIXME should be user controllable via propertiesa. +*/ + sprctl |= SPRITE_GAMMA_ENABLE; + if (obj-tiling_mode != I915_TILING_NONE) sprctl |= SPRITE_TILED; @@ -453,6 +465,12 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc *crtc, BUG(); } + /* +* Enable gamma to match primary/cursor plane behaviour. +* FIXME should be user controllable via propertiesa. +*/ + dvscntr |= DVS_GAMMA_ENABLE; + if (obj-tiling_mode != I915_TILING_NONE) dvscntr |= DVS_TILED; -- 1.8.3.1 -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] drm/i915: Do hw quiescing first during unload
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
If we force the hw to idle as our first step during unload, we can abort
the unload upon failure. Later we can probe whether the hardware remain
active even after we try to shut it down.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0cab2d0..479abc0 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1704,6 +1704,12 @@ int i915_driver_unload(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int ret;
+ ret = i915_gem_suspend(dev);
+ if (ret) {
+ DRM_ERROR(failed to idle hardware: %d\n, ret);
+ return ret;
+ }
+
intel_gpu_ips_teardown();
if (HAS_POWER_WELL(dev)) {
@@ -1719,10 +1725,6 @@ int i915_driver_unload(struct drm_device *dev)
if (dev_priv-mm.inactive_shrinker.scan_objects)
unregister_shrinker(dev_priv-mm.inactive_shrinker);
- ret = i915_gem_suspend(dev);
- if (ret)
- DRM_ERROR(failed to idle hardware: %d\n, ret);
-
io_mapping_free(dev_priv-gtt.mappable);
arch_phys_wc_del(dev_priv-gtt.mtrr);
--
1.8.3.1
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/9] drm-intel-collector - update
Hi Daniel, I was missing a rebase on testing. Anyway, collector is now updated and all patches there are reviewed. Thanks On Tue, Nov 19, 2013 at 9:25 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: On Mon, Nov 18, 2013 at 7:28 PM, Ausmus, James james.aus...@intel.com wrote: On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: This is another drm-intel-collector updated notice: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the update list in order for better reviewers assignment: Patch drm/i915: Asynchronously perform the set-base for a simple modeset - Reviewed by me. Patch drm/i915: Fix gen3/4 vblank counter wraparound - Reviewer: Patch drm/i915: Use frame counter for intel_wait_for_vblank() on CTG - Reviewer: Patch drm/i915: Do hw quiescing first during unload - Reviewer: Patch drm/i915: print object bindings in debugfs - Reviewer: Patch drm/i915/vlv: enable HDMI audio for Valleyview2 - Reviewer: Patch drm/i915: Hold pc8 lock around toggling pc8.gpu_idle - Reviewed by Paulo Patch drm/i915: Do not enable package C8 on unsupported hardware - Reviewed by Paulo Patch drm/i915: Enable pipe gamma for sprites - Reviewer: Overall Process: drm-intel-collector - review request 1. Daniel pushs drm-intel-testing (every 2 weeks) 2. I rebase drm-intel-collector onto drm-intel-testing 3. Add Reviewer: tag with voluntered reviewers. If you don't believe you should be assigned on a particular patch please don't get mad just tell you wont review or volunteer someone else. 4. I resubmit remaining patches for review without picking any new (drm-intel-collector - review request) drm-intel-collector - updated 5. One week later I collect all simple (1-2) patches that wasn't yet reviewed and not queued by Daniel from one testing update until another. 6. Request automated QA's PRTS automated i-g-t tests comparing drm-intel-testing x drm-intel-collector 7. If tests are ok I send the update notification or the patches as a series to intel-gfx mailing list for better tracking and to be reviewed. (drm-intel-collector - updated) 8. Let me know volunteers for review new patches and also let me know if I've picked any patch that I shouldn't. There are some reasons that some patches can be left behind: 1. Your patch didn't applied cleanly and I couldn't easily solve the conflicts. 2. Kernel didn't compiled with your patch. 3. I simply missed it. If you believe this is the case please warn me. Please help me to get these patches reviewed and queued by Daniel. Also, please let me know if you have further ideas how to improve this process. Thanks in advance, Rodrigo. Chris Wilson (4): drm/i915: Asynchronously perform the set-base for a simple modeset drm/i915: Do hw quiescing first during unload drm/i915: Hold pc8 lock around toggling pc8.gpu_idle drm/i915: Do not enable package C8 on unsupported hardware Daniel Vetter (1): drm/i915: print object bindings in debugfs Mengdong Lin (1): drm/i915/vlv: enable HDMI audio for Valleyview2 A v4 of this patch was already merged in with a slightly renamed subject: 9ca2fe731b3f12afbc97cf0050dfa4184bd2234c drm/i915/vlv: enable HDA display audio for Valleyview2 Thank you for the warn. I'll remove it. -James Ville Syrjälä (3): drm/i915: Fix gen3/4 vblank counter wraparound drm/i915: Use frame counter for intel_wait_for_vblank() on CTG drm/i915: Enable pipe gamma for sprites drivers/gpu/drm/i915/i915_debugfs.c | 6 drivers/gpu/drm/i915/i915_dma.c | 10 +++--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_irq.c | 2 +- drivers/gpu/drm/i915/i915_reg.h | 20 ++- drivers/gpu/drm/i915/intel_display.c | 65 drivers/gpu/drm/i915/intel_sprite.c | 18 ++ 7 files changed, 103 insertions(+), 19 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: Add VLV specific force wake routines.
On Thu, 14 Nov 2013 19:02:15 +0530 deepa...@intel.com wrote: From: Deepak S deepa...@intel.com Added media/render/common well VLV force wake routines to help bring up the WELLS before access the register - Refactor current vlv_forcewake get/put and added MEDIA or RENDER specific Forcewake. - Added VLV Check to bring up MEDIA and RENDER WELL base on the register accessed in vlv_read##x (in intel_uncore.c) This patch is pretty big and so a bit hard to review. A couple of questions: - why not use the callback to __vlv_force_wake_* from gen6_gt_force_wake_*? i.e. why is VLV special here? - having a new gen7_media_force_wake function may be better than passing an engine around, and would touch fewer pieces of code - have you done measurements on this? given how infrequently we ought to be waking the wells when they're idle, and how long we generally keep them awake, is this a real power win? Thanks, Jesse ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix fbc + rc6 combination on SNB
On Tue, Nov 19, 2013 at 2:39 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Nov 19, 2013 at 3:08 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: I'm just on going with another -collector update and since this patch fixes a bug I think it would be a good one to include. But since it was bikeshedded it is better to ask Ville and Chris if their comments was a NAck or I can consider to get for -collector. It's more a meh, since as long as we don't enable fbc by default it won't really benefit upstream much at all. These two patches fix real FBC issues here, letting us enable it and save power. I think it's worth considering them for inclusion. Stéphane -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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
