Re: [Intel-gfx] Find bugs in i915 driver
Am Montag, den 13.08.2012, 03:08 + schrieb Xu, Anhua:
Sorry, Deniel/Greg, late response for your email because of a busy work last
work.
I will response to you guys ASAP :), below is the updated patch:
From 33eb95a3a711b2354985361ff208ea150a5ba235 Mon Sep 17 00:00:00 2001
From: Xu Anhua anhua...@intel.com
If Anhua is your first name your name is still switched here.
Please do the following.
git commit --amend --author=Anhua Xu anhua...@intel.com
Date: Tue, 31 Jul 2012 17:16:50 +0800
Subject: [PATCH] drm/i915: fix wrong order of parameters in port checking
functions
Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
This bug was indroduced by commit
1519b9956eb4b4180fa3f47c73341463cdcfaa37
Since it is hard to remember commit hashes, you should add the following
summary
commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
Author: Keith Packard kei...@keithp.com
Date: Sat Aug 6 10:35:34 2011 -0700
drm/i915: Fix PCH port pipe select in CPT disable paths
or just the following.
1519b995 drm/i915: Fix PCH port pipe select in CPT disable paths
The reachable tag for this commit is v3.1-rc1-3-g1519b99
Then this should be sent to stable [1] too?
Cc: sta...@vger.kernel.org
Does this actually fix a bug you are seeing or did you just spot this
reading the code?
Signed-off-by: Anhua Xu anhua...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f615976..5fc8c8d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1383,7 +1383,7 @@ static void assert_pch_hdmi_disabled(struct
drm_i915_private *dev_priv,
enum pipe pipe, int reg)
{
u32 val = I915_READ(reg);
- WARN(hdmi_pipe_enabled(dev_priv, val, pipe),
+ WARN(hdmi_pipe_enabled(dev_priv, pipe, val),
PCH HDMI (0x%08x) enabled on transcoder %c, should be disabled\n,
reg, pipe_name(pipe));
@@ -1403,13 +1403,13 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
reg = PCH_ADPA;
val = I915_READ(reg);
- WARN(adpa_pipe_enabled(dev_priv, val, pipe),
+ WARN(adpa_pipe_enabled(dev_priv, pipe, val),
PCH VGA enabled on transcoder %c, should be disabled\n,
pipe_name(pipe));
reg = PCH_LVDS;
val = I915_READ(reg);
- WARN(lvds_pipe_enabled(dev_priv, val, pipe),
+ WARN(lvds_pipe_enabled(dev_priv, pipe, val),
PCH LVDS enabled on transcoder %c, should be disabled\n,
pipe_name(pipe));
@@ -1871,7 +1871,7 @@ static void disable_pch_hdmi(struct drm_i915_private
*dev_priv,
enum pipe pipe, int reg)
{
u32 val = I915_READ(reg);
- if (hdmi_pipe_enabled(dev_priv, val, pipe)) {
+ if (hdmi_pipe_enabled(dev_priv, pipe, val)) {
DRM_DEBUG_KMS(Disabling pch HDMI %x on pipe %d\n,
reg, pipe);
I915_WRITE(reg, val ~PORT_ENABLE);
@@ -1893,12 +1893,12 @@ static void intel_disable_pch_ports(struct
drm_i915_private *dev_priv,
reg = PCH_ADPA;
val = I915_READ(reg);
- if (adpa_pipe_enabled(dev_priv, val, pipe))
+ if (adpa_pipe_enabled(dev_priv, pipe, val))
I915_WRITE(reg, val ~ADPA_DAC_ENABLE);
reg = PCH_LVDS;
val = I915_READ(reg);
- if (lvds_pipe_enabled(dev_priv, val, pipe)) {
+ if (lvds_pipe_enabled(dev_priv, pipe, val)) {
DRM_DEBUG_KMS(disable lvds on pipe %d val 0x%08x\n, pipe,
val);
I915_WRITE(reg, val ~LVDS_PORT_EN);
POSTING_READ(reg);
With the changes addressed above, please add
Acked-by: Paul Menzel paulepan...@users.sourceforge.net
when sending [PATCH v3] as documented in [2].
Thanks,
Paul
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/stable_kernel_rules.txt;h=b0714d8f678ac51d0c280a4f5f2980196052421f;hb=HEAD
[2]
http://wireless.kernel.org/en/developers/Documentation/git-guide#Annotating_new_revision
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] Find bugs in i915 driver
On Mon, Aug 13, 2012 at 03:08:33AM +, Xu, Anhua wrote: Sorry, Deniel/Greg, late response for your email because of a busy work last work. I will response to you guys ASAP :), below is the updated patch: From 33eb95a3a711b2354985361ff208ea150a5ba235 Mon Sep 17 00:00:00 2001 From: Xu Anhua anhua...@intel.com Date: Tue, 31 Jul 2012 17:16:50 +0800 Subject: [PATCH] drm/i915: fix wrong order of parameters in port checking functions Wrong order of parameters passed-in when calling hdmi/adpa /lvds_pipe_enabled(), 2nd and 3rd parameters are reversed. This bug was indroduced by commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37 The reachable tag for this commit is v3.1-rc1-3-g1519b99 Signed-off-by: Anhua Xu anhua...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Find bugs in i915 driver
Hi, Paul
Thanks for your advice. I update my patch. Please review, for your question,
please see my reply below.
From d11080eda81c0503b5035ea40667b06fe2ee0fb5 Mon Sep 17 00:00:00 2001
From: Anhua Xu anhua...@intel.com
Date: Tue, 31 Jul 2012 17:16:50 +0800
Subject: [PATCH v3] drm/i915: fix wrong order of parameters in port checking
functions
Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
This bug was indroduced by below commit:
commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
Author: Keith Packard kei...@keithp.com
Date: Sat Aug 6 10:35:34 2011 -0700
drm/i915: Fix PCH port pipe select in CPT disable paths
The reachable tag for this commit is v3.1-rc1-3-g1519b99
Signed-off-by: Anhua Xu anhua...@intel.com
Acked-by: Paul Menzel paulepan...@users.sourceforge.net
---
drivers/gpu/drm/i915/intel_display.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f615976..5fc8c8d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1383,7 +1383,7 @@ static void assert_pch_hdmi_disabled(struct
drm_i915_private *dev_priv,
enum pipe pipe, int reg)
{
u32 val = I915_READ(reg);
- WARN(hdmi_pipe_enabled(dev_priv, val, pipe),
+ WARN(hdmi_pipe_enabled(dev_priv, pipe, val),
PCH HDMI (0x%08x) enabled on transcoder %c, should be disabled\n,
reg, pipe_name(pipe));
@@ -1403,13 +1403,13 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
reg = PCH_ADPA;
val = I915_READ(reg);
- WARN(adpa_pipe_enabled(dev_priv, val, pipe),
+ WARN(adpa_pipe_enabled(dev_priv, pipe, val),
PCH VGA enabled on transcoder %c, should be disabled\n,
pipe_name(pipe));
reg = PCH_LVDS;
val = I915_READ(reg);
- WARN(lvds_pipe_enabled(dev_priv, val, pipe),
+ WARN(lvds_pipe_enabled(dev_priv, pipe, val),
PCH LVDS enabled on transcoder %c, should be disabled\n,
pipe_name(pipe));
@@ -1871,7 +1871,7 @@ static void disable_pch_hdmi(struct drm_i915_private
*dev_priv,
enum pipe pipe, int reg)
{
u32 val = I915_READ(reg);
- if (hdmi_pipe_enabled(dev_priv, val, pipe)) {
+ if (hdmi_pipe_enabled(dev_priv, pipe, val)) {
DRM_DEBUG_KMS(Disabling pch HDMI %x on pipe %d\n,
reg, pipe);
I915_WRITE(reg, val ~PORT_ENABLE);
@@ -1893,12 +1893,12 @@ static void intel_disable_pch_ports(struct
drm_i915_private *dev_priv,
reg = PCH_ADPA;
val = I915_READ(reg);
- if (adpa_pipe_enabled(dev_priv, val, pipe))
+ if (adpa_pipe_enabled(dev_priv, pipe, val))
I915_WRITE(reg, val ~ADPA_DAC_ENABLE);
reg = PCH_LVDS;
val = I915_READ(reg);
- if (lvds_pipe_enabled(dev_priv, val, pipe)) {
+ if (lvds_pipe_enabled(dev_priv, pipe, val)) {
DRM_DEBUG_KMS(disable lvds on pipe %d val 0x%08x\n, pipe,
val);
I915_WRITE(reg, val ~LVDS_PORT_EN);
POSTING_READ(reg);
--
1.7.1
-Original Message-
From: Paul Menzel [mailto:paulepan...@users.sourceforge.net]
Sent: Monday, August 13, 2012 3:11 PM
To: Xu, Anhua
Cc: Daniel Vetter; Greg KH; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] Find bugs in i915 driver
Am Montag, den 13.08.2012, 03:08 + schrieb Xu, Anhua:
Sorry, Deniel/Greg, late response for your email because of a busy work last
work.
I will response to you guys ASAP :), below is the updated patch:
From 33eb95a3a711b2354985361ff208ea150a5ba235 Mon Sep 17 00:00:00
2001
From: Xu Anhua anhua...@intel.com
If Anhua is your first name your name is still switched here.
Please do the following.
git commit --amend --author=Anhua Xu anhua...@intel.com
Date: Tue, 31 Jul 2012 17:16:50 +0800
Subject: [PATCH] drm/i915: fix wrong order of parameters in port
checking functions
Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
This bug was indroduced by commit
1519b9956eb4b4180fa3f47c73341463cdcfaa37
Since it is hard to remember commit hashes, you should add the following
summary
commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
Author: Keith Packard kei...@keithp.com
Date: Sat Aug 6 10:35:34 2011 -0700
drm/i915: Fix PCH port pipe select in CPT disable paths
or just the following.
1519b995 drm/i915: Fix PCH port pipe select in CPT disable paths
The reachable tag for this commit is v3.1-rc1-3-g1519b99
Then this should be sent to stable [1] too?
Cc: sta...@vger.kernel.org
Does this actually fix a bug you are seeing or
Re: [Intel-gfx] [PATCH] agp/intel, drm/i915: Use a write-combining map for updating PTEs
On Sun, Aug 12, 2012 at 08:12:02PM +0100, Chris Wilson wrote: On Sun, 12 Aug 2012 17:01:08 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sun, 12 Aug 2012 17:47:46 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Aug 12, 2012 at 12:04:39PM +0100, Chris Wilson wrote: In order to be able to ioremap_wc the GTT space, we need to remove the conflicting pci_iomap from drm/i915, so we limit the register map in drm/i915 to the suitable range for each generation. The benefit of doing this is an order of magnitude reduction in time spent rewriting the GTT entries when inserting and removing objects. For example, this halves the CPU time spent in X when pushing pixels for chromium through a userptr (chromium has a bug where it likes to recreate its ShmPixmap on every draw). Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk How well does this work with ums? I guess if it blows up, we could ioremap uncached, but when kms initializes drop that uc mapping and try to remap wc. But I fear that ums will map the entire bar and hence we can't just unconditionally map the gatt wc. It will work equisitely with ums. It will fail to do as it wishes and fallback to VESA and everybody will be much happier... So having rediscovered the hard truth that i915.modeset=1 and xf86-video-2.6.0 results in nasty hangs, setting the GTT table to WC has no effect upon the ancient UMS module - it shows the retro background and appears to function. We struck lucky. \o/ Ok, let's them the wrath of the abi gods. Merged to -queued, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] GMBUS EDID read bit-banging fallback
Alex, Maciej, please test the following to see if it fixes the issue [1], thanks. BR, Jani. [1] https://bugzilla.kernel.org/show_bug.cgi?id=45881 Jani Nikula (2): drm/i915: extract connector update from intel_ddc_get_modes() for reuse drm/i915: fall back to bit-banging if GMBUS fails in CRT EDID reads drivers/gpu/drm/i915/intel_crt.c | 36 +--- drivers/gpu/drm/i915/intel_drv.h |2 ++ drivers/gpu/drm/i915/intel_modes.c | 31 ++- 3 files changed, 57 insertions(+), 12 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.6 haswell regression from v3.5?
I'm struggling to get back to a version that works on the Shark Bay / Haswell platform that I have. I did get it to work once...but have since updated the BIOS, so am not sure if that may have an effect on this test. v3.5 also gave a stack (below) - so without a working version, I cannot do the bisecting. Perhaps it is just too early in the Haswell dev cycle for me to try to get this working? [ 16.599822] [ cut here ] [ 16.605099] WARNING: at /data/home/bguthro/dev/newdev-tip/linux-3.5/drivers/gpu/drm/i915/intel_display.c:976 assert_fdi_tx+0x87/0x90 [i915]() [ 16.619568] Hardware name: Shark Bay Client platform [ 16.625244] FDI TX state assertion failure (expected off, current on) [ 16.632632] Modules linked in: ahci(+) libahci crc32c_intel e1000e(+) ehci_hcd(+) i915(+) drm_kms_helper drm i2c_algo_bit video xhci_hcd intel_agp intel_gtt [ 16.648576] Pid: 142, comm: modprobe Not tainted 3.5.0-orc #14 [ 16.655275] Call Trace: [ 16.658130] [8104f67f] warn_slowpath_common+0x7f/0xc0 [ 16.665023] [8104f776] warn_slowpath_fmt+0x46/0x50 [ 16.665058] usb 1-11: new low-speed USB device number 2 using xhci_hcd [ 16.679111] [a00b8c57] assert_fdi_tx+0x87/0x90 [i915] [ 16.686001] [a00bdd65] ironlake_crtc_disable+0x185/0x820 [i915] [ 16.689451] usb 1-11: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes [ 16.703942] [a00be48e] ironlake_crtc_dpms+0x8e/0xa0 [i915] [ 16.711309] [a00b9bc8] intel_crtc_dpms+0x48/0x140 [i915] [ 16.718487] [a00c1af5] intel_crtc_disable+0x35/0xb0 [i915] [ 16.721916] usbcore: registered new interface driver usbhid [ 16.721917] usbhid: USB HID core driver [ 16.736714] [a008c6a5] drm_helper_disable_unused_functions+0x115/0x190 [drm_kms_helper] [ 16.746959] [a00c3ba7] intel_modeset_init+0x687/0xe50 [i915] [ 16.754536] [a009cd3a] i915_driver_load+0xa9a/0xb80 [i915] [ 16.761932] [a003aa7b] ? drm_get_minor+0x26b/0x310 [drm] [ 16.769086] [a003ce71] drm_get_pci_dev+0x191/0x2b0 [drm] [ 16.776278] [8157801e] ? _raw_spin_unlock_irqrestore+0x1e/0x30 [ 16.784065] [a00e5917] i915_pci_probe+0x1b/0x1d [i915] [ 16.791041] [812da410] pci_device_probe+0xb0/0x140 [ 16.797631] [813909be] driver_probe_device+0x7e/0x220 [ 16.804527] [81390c0b] __driver_attach+0xab/0xb0 [ 16.810929] [81390b60] ? driver_probe_device+0x220/0x220 [ 16.818106] [8138ede6] bus_for_each_dev+0x56/0x90 [ 16.824609] [813904ce] driver_attach+0x1e/0x20 [ 16.830814] [81390080] bus_add_driver+0x1a0/0x270 [ 16.837305] [81391166] driver_register+0x76/0x130 [ 16.843805] [812da135] __pci_register_driver+0x55/0xd0 [ 16.850795] [8157bdcd] ? notifier_call_chain+0x4d/0x70 [ 16.857786] [a003d0aa] drm_pci_init+0x11a/0x130 [drm] [ 16.859591] usb 1-12: new low-speed USB device number 3 using xhci_hcd [ 16.872169] [a0116000] ? 0xa0115fff [ 16.878075] [a011608b] i915_init+0x8b/0x8d [i915] [ 16.884568] [8100203f] do_one_initcall+0x3f/0x170 [ 16.887716] usb 1-12: ep 0x81 - rounding interval to 128 microframes, ep desc says 192 microframes [ 16.901316] [810affcf] sys_init_module+0x8f/0x200 [ 16.907797] [81580069] system_call_fastpath+0x16/0x1b [ 16.914692] ---[ end trace 941488b1333d181e ]--- On Fri, Aug 10, 2012 at 10:21 PM, Ben Guthro b...@guthro.net wrote: I'll try to do this early next week, and report back. On Fri, Aug 10, 2012 at 7:37 PM, Ben Widawsky b...@bwidawsk.net wrote: On 2012-08-10 09:25, Ben Guthro wrote: Hello, I've been attempting to get a Shark Bay / Haswell platform up running, and have been having some difficulties that I'm hoping you all can possibly help with. I first tried the 3.5 kernel, and had some success after applying the following patch: https://patchwork.kernel.org/patch/1229541/ This seemed to be necessary to get the 0x0c26 PCI id to be loaded by i915, and use KMS. After doing this, I had some success, but things still would become unstable, and flash test patterns on the screen about every third boot. I figured that I would move on to the tip, and see if that fixed anything. However, at the tip, I cannot get i915 to display graphics at all - even with applying the patch above. I understand that this is still under development - but this seems like a regression from 3.5 Is there a codebase that I should be using for this testing? Yes it is the codebase you should use. It sounds like a regression, can you bisect it? Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center
[Intel-gfx] [PATCH 0/1] hopefully fix null pointer dereference on i915 load
Hi Mihai, could you test the following patch to see if it fixes the problem, please? BR, Jani. Jani Nikula (1): drm/i915: ensure i2c adapter is all set before adding it drivers/gpu/drm/i915/intel_i2c.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v3.5 Oops in i2c_algo_bit.c:bit_xfer+0x23/0x870: i915 or i2c?
On Mon, 13 Aug 2012, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Aug 12, 2012 at 11:49:22PM -0400, George Spelvin wrote: (Bringing this back to the mailing lists after a bit of uninteresting private conversation.) Honestly, I think we need a way to force disable gmbus with a module parameter or something anyway. It's not the first time gmbus has been implicated with an issue. Maybe it even exists already, but I couldn't find this. So if you confirm that fixes the problem for you on the ml, at least maybe such a patch will be the result. If you feel it's a software bug (which I agree it seems likely), a bisect is always much appreciated. Personally, I'll usually step back major releases until something works, or I hit 3.2ish. Even knowing it never worked through 3.2 is helpful. It's a friend's machine, which I normally only have remote access to, so it's a bit pf a pain, but I can manage. I just thought a basic i3 motherboard was so common I couldn't possibly be the only one with this problem. Here's the 3.2 dmesg showing the fallback working, but this is an Ubuntu-patched kernel (linux-image-3.2.0-29-generic) that may be a fair distance from stock: One thing of interest would be the exact .config you use to build the kernel and the output of lsmod (after the kernel crashed). I guess the issue is with the combination of drivers you have (i2c_detect in the calltrace calls back into other registered i2c drivers ...). Hi all, this smells a bit like [1], don't you think? George, can you check the patch I just sent to (hopefully) fix that issue? Thanks. BR, Jani. [1] http://thread.gmane.org/gmane.linux.kernel/1339794 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/1] hopefully fix null pointer dereference on i915 load
On Mon, Aug 13, 2012 at 05:03:24PM +0200, Mihai Moldovan wrote: Hi Jani, * On 13.08.2012 04:33 PM, Jani Nikula wrote: Hi Mihai, could you test the following patch to see if it fixes the problem, please? BR, Jani. Jani Nikula (1): drm/i915: ensure i2c adapter is all set before adding it drivers/gpu/drm/i915/intel_i2c.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) The reason sounds sane to me, but while looking through the code, I have seen a few other problems, too. To my understanding, we should use port for dev_priv-gmbus[], not the pin mapping (which is only used for gmbus_ports[]). Don't forget to add the +1 for pin - port mapping to the error case. Also, intel_gmbus_get_adapter is already accepting a port value (I made sure to look at the calls in other files too), so don't map the port back to a pin. Keep the same in mind for the intel_teardown_gmbus destructor. The current code adds the gmbus algorithm (gmbus_xfer) to gmbus port 0, which is known as disabled and shouldn't be used (previously has_gpio was set to false for those ports to not do any transfer on those ports.) I may be wrong, could you review this and maybe add it to your patch? This seems to essentially undo commit 2ed06c93a1fce057808894d73167aae03c76deaf Author: Daniel Kurtz djku...@chromium.org Date: Wed Mar 28 02:36:15 2012 +0800 drm/i915/intel_i2c: gmbus disabled and reserved ports are invalid Note that port numbers start at 1, whereas the array is 0-index based. So you patch here would blow up if you don't extend the dev_priv-gmbus array. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] Intel xorg driver 2.20.2 overlay off-by-one bug
On Sun, 12 Aug 2012 10:01:44 +0100, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
While reading through the Intel driver code, I spotted this in
I830SetPortAttributeOverlay:
} else if (attribute == xvPipe) {
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
if ((value -1) || (value xf86_config-num_crtc))
return BadValue;
if (value 0)
adaptor_priv-desired_crtc = NULL;
else
adaptor_priv-desired_crtc = xf86_config-crtc[value];
This allows value == xf86_config-num_crtc to be valid, which would be
the CRTC number _after_ the last one in the array. Presumably this is
not desired, and the test should be =.
Thanks for bringing this to our attention and poking Dave, who promptly
pushed a patch to fix the bug.
-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 0/7] modeset rework prep patches
On Sun, Aug 12, 2012 at 08:47:56PM +0100, Chris Wilson wrote: On Sun, 12 Aug 2012 19:27:07 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, I've noticed that a few prep patches of the modeset rework series haven't been merged nor reviewed yet, so I've split them out in this resend. Mostly concern really old gen2 stuff (dvo + pipe A quirk), but little patches in other areas. Commentsreview highly welcome. Thanks, Daniel Daniel Vetter (7): drm/i915: add missing gen2 pipe A quirk entries I remain dubious whether the 855gm entry is genuine. drm/i915/ns2501: kill pll A enabling hack drm/i915: rip out the overlay pipe A workaround Look fine and a welcome reduction in code + confusion. drm/i915: prepare load-detect pipe code for dpms changes It is not immediately obvious from the function that there is a relationship between the connector and intel_encoder. If we derived the encoder from the connector in that function, the reviewer's life gets a little easier. As it stands the code looks correct and rightly removes some internal details. drm/i915: simplify dvo dpms interface This just looks like churn for churn's sake? The changes look correct. drm/i915: kill a few unused things in dev_priv +1 drm/i915: extract ironlake_fdi_pll_disable Smaller more descriptive functions, what is not to like. 2-7: Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk You can have an r-b for 1 if you drop the 855gm chunk. Then get someone else to a-b the 855gm entry :) I've slurped in the revised series, thanks a lot for the review. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after display_bpc is set
display_bpc might not have been set before comparing with the
requested mode, so wait until afterwards before comparing with the
supported fdi bandwidth. Not a significant change as any case that
mattered would have worked; this just makes the debug messages look nicer.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 39 --
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 95248bd..b099a17 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3804,15 +3804,6 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc
*crtc,
display_bpc = 6;
}
- if (display_bpc * 3 max_fdi_bpp) {
- if (max_fdi_bpp 24)
- display_bpc = 6;
- else if (max_fdi_bpp 30)
- display_bpc = 8;
- else if (max_fdi_bpp 36)
- display_bpc = 10;
- DRM_DEBUG_KMS(Dithering FDI to %dbpc\n, display_bpc);
- }
/*
* We could just drive the pipe at the highest bpc all the time and
* enable dithering as needed, but that costs bandwidth. So choose
@@ -3845,8 +3836,20 @@ static bool intel_choose_pipe_bpp_dither(struct drm_crtc
*crtc,
display_bpc = min(display_bpc, bpc);
- DRM_DEBUG_KMS(setting pipe bpc to %d (max display bpc %d)\n,
- bpc, display_bpc);
+ display_bpc = 6;
+
+ if (display_bpc * 3 max_fdi_bpp) {
+ if (max_fdi_bpp 24)
+ display_bpc = 6;
+ else if (max_fdi_bpp 30)
+ display_bpc = 8;
+ else if (max_fdi_bpp 36)
+ display_bpc = 10;
+ DRM_DEBUG_KMS(Dithering FDI to %dbpc\n, display_bpc);
+ }
+
+ DRM_DEBUG_KMS(setting pipe bpc to %d (max display bpc %d) (max_fdi_bpp
%d)\n,
+ bpc, display_bpc, max_fdi_bpp);
*pipe_bpp = display_bpc * 3;
@@ -4737,8 +4740,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
max_fdi_bpp = 0;
max_lane = lane;
} else {
- u32 fdi_bw;
-
+ u32 fdi_bw, pps;
/* [e]DP over FDI requires target mode clock
instead of link clock */
if (is_dp)
@@ -4763,9 +4765,12 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
* Compute the available FDI bandwidth, use that
* to compute the maximum supported BPP
*/
- fdi_bw = link_bw * max_lane * 19 / 20;
- max_fdi_bpp = fdi_bw / target_clock;
- DRM_DEBUG_KMS(max lane %d yields max fdi bpp %d\n, max_lane,
max_fdi_bpp);
+ fdi_bw = (link_bw * 8) * max_lane;
+ pps = target_clock * 21 / 20;
+
+ max_fdi_bpp = fdi_bw / pps;
+ DRM_DEBUG_KMS(link_bw %d max_lane %d fdi_bw %u pps %u
max_fdi_bpp %d\n,
+ link_bw, max_lane, fdi_bw, pps, max_fdi_bpp);
}
/* [e]DP over FDI requires target mode clock instead of link clock. */
@@ -4809,6 +4814,8 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
*/
u32 bps = target_clock * pipe_bpp * 21 / 20;
lane = bps / (link_bw * 8) + 1;
+ DRM_DEBUG_KMS(target_clock %u pipe_bpp %u bps %u link_bw %u
lane %u\n,
+ target_clock, pipe_bpp, bps, link_bw, lane);
if (lane max_lane) {
DRM_ERROR(Not enough lanes available for mode! (want
%d have %d)\n,
lane, max_lane);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] drm/i915: IVB FDI B/C fixes and misc cleanups
This is the complete set of patches that yield a working 3-pipe mode setting configuration on my test machines. It does not make DPMS work, so I still need to figure that out. As the DPMS paths are almost entirely different from mode setting (whose crazy idea was that, anyway?), that may take a bit more time. I've managed to reproduce this bug with only two monitors just by forcing them onto FDI B/C, but only with 1920x1080 and larger modes: $ xrandr --output VGA1 --off --output DP1 --off $ xrandr --output VGA1 --auto --crtc 1 $ xrandr --output DP1 --auto --crtc 2 That works about 50% of the time on the original kernel. If it works, you can just try a couple of different modes to see if you can get it to fail. Just use reasonably large modes -- 640x480 has never failed for me. I'd love to know why $ xrandr --output DP1 --mode 1600x1200 --crtc 2 Finally, the X server has a terrible bug in the RandR code. It computes a desired initial configuration, and if that fails in any way, it refuses to start at all. So, if you connect three monitors that all require separate PLLs, then you get two monitors lit up, the third one fails and the X server aborts. Need to fix that so that if *any* monitors light up, the X server will keep going. *** The patches: *** [PATCH 1/7] drm/i915: Allow VGA on CRTC 2 Silly hold-over from the bad-old PLL sharing code. [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge Here's the patch which rejects modes that the FDI B/C lane sharing hardware can't support. This only affects modes larger than 1920x1200 though as that mode and smaller all fit in two FDI lanes. I ran across this while testing with a 2560x1200 monitor. [PATCH 3/7] drm/i915: Delay between FDI link training tries. Clear This seems like a sensible change in the FDI link training code -- gives the FDI hardware time to adapt to changes in the signalling. But, as I've never seen FDI fail to train, I'm not sure it's useful. [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after This mostly just cleans up some debug messages by moving various BPP computations around. should have no effect on the hardware. [PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR Just happened across this obvious bug while reading through the driver. [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX The specs don't say which order to do this in, but it doesn't make sense to do these in the current order. With this in place, I saw mode setting errors reduced quite a bit, but not gone. [PATCH 7/7] drm/i915: Merge FDI RX reg writes during training This may be the only patch necessary to get mode setting working on FDI-B/C, it ensures that error correction is always turned on during link training. The old code left error correction disabled as there was no posting read after setting that. I'm hoping this explains why the problem wasn't reliably reproducible -- the problem depended on how long the write waited to get to the hardware. I haven't done enough testing of this patch in isolation to know if this is true or not. -keith ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR
These should probably all look like enabled |= (1 pipe) so that the intent is clear... Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/intel_pm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 94aabca..1a84425 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1815,7 +1815,7 @@ static void sandybridge_update_wm(struct drm_device *dev) DRM_DEBUG_KMS(FIFO watermarks For pipe C - plane %d, cursor: %d\n, plane_wm, cursor_wm); - enabled |= 3; + enabled |= 4; } /* -- 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/7] drm/i915: Delay between FDI link training tries. Clear FDI_RX_IIR before training
Just a bit of cleanup; it appears to have no effect.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7106807..95248bd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2391,6 +2391,7 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)
temp |= FDI_LINK_TRAIN_PATTERN_1;
I915_WRITE(reg, temp | FDI_TX_ENABLE);
+ I915_WRITE(FDI_RX_IIR(pipe), FDI_RX_BIT_LOCK);
reg = FDI_RX_CTL(pipe);
temp = I915_READ(reg);
temp = ~FDI_LINK_TRAIN_NONE;
@@ -2398,10 +2399,10 @@ static void ironlake_fdi_link_train(struct drm_crtc
*crtc)
I915_WRITE(reg, temp | FDI_RX_ENABLE);
POSTING_READ(reg);
- udelay(150);
/* Ironlake workaround, enable clock pointer after FDI enable*/
if (HAS_PCH_IBX(dev)) {
+ udelay(150);
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR);
I915_WRITE(FDI_RX_CHICKEN(pipe), FDI_RX_PHASE_SYNC_POINTER_OVR |
FDI_RX_PHASE_SYNC_POINTER_EN);
@@ -2409,6 +2410,7 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)
reg = FDI_RX_IIR(pipe);
for (tries = 0; tries 5; tries++) {
+ udelay(150);
temp = I915_READ(reg);
DRM_DEBUG_KMS(FDI_RX_IIR 0x%x\n, temp);
@@ -2422,6 +2424,7 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)
DRM_ERROR(FDI train 1 fail!\n);
/* Train 2 */
+ I915_WRITE(FDI_RX_IIR(pipe), FDI_RX_SYMBOL_LOCK);
reg = FDI_TX_CTL(pipe);
temp = I915_READ(reg);
temp = ~FDI_LINK_TRAIN_NONE;
@@ -2435,10 +2438,10 @@ static void ironlake_fdi_link_train(struct drm_crtc
*crtc)
I915_WRITE(reg, temp);
POSTING_READ(reg);
- udelay(150);
reg = FDI_RX_IIR(pipe);
for (tries = 0; tries 5; tries++) {
+ udelay(150);
temp = I915_READ(reg);
DRM_DEBUG_KMS(FDI_RX_IIR 0x%x\n, temp);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX
Doesn't make sense to disable in the other order. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/intel_display.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b099a17..754f10f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2776,17 +2776,17 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc) u32 reg, temp; /* disable CPU FDI tx and PCH FDI rx */ - reg = FDI_TX_CTL(pipe); - temp = I915_READ(reg); - I915_WRITE(reg, temp ~FDI_TX_ENABLE); - POSTING_READ(reg); - reg = FDI_RX_CTL(pipe); temp = I915_READ(reg); temp = ~(0x7 16); temp |= (I915_READ(PIPECONF(pipe)) PIPE_BPC_MASK) 11; I915_WRITE(reg, temp ~FDI_RX_ENABLE); + POSTING_READ(reg); + udelay(100); + reg = FDI_TX_CTL(pipe); + temp = I915_READ(reg); + I915_WRITE(reg, temp ~FDI_TX_ENABLE); POSTING_READ(reg); udelay(100); -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915: Merge FDI RX reg writes during training
Need to turn on the error correction when enabling training or it might not get enabled in time. This seems to fix the FDI-B/FDI-C link training problem. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/intel_display.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 754f10f..1d24d55 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2324,6 +2324,8 @@ static void intel_fdi_normal_train(struct drm_crtc *crtc) temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE; } I915_WRITE(reg, temp); + POSTING_READ(reg); + udelay(100); reg = FDI_RX_CTL(pipe); temp = I915_READ(reg); @@ -2334,16 +2336,15 @@ static void intel_fdi_normal_train(struct drm_crtc *crtc) temp = ~FDI_LINK_TRAIN_NONE; temp |= FDI_LINK_TRAIN_NONE; } + /* IVB wants error correction enabled */ + if (IS_IVYBRIDGE(dev)) + temp |= FDI_FS_ERRC_ENABLE | FDI_FE_ERRC_ENABLE; + I915_WRITE(reg, temp | FDI_RX_ENHANCE_FRAME_ENABLE); /* wait one idle pattern time */ POSTING_READ(reg); udelay(1000); - - /* IVB wants error correction enabled */ - if (IS_IVYBRIDGE(dev)) - I915_WRITE(reg, I915_READ(reg) | FDI_FS_ERRC_ENABLE | - FDI_FE_ERRC_ENABLE); } static void cpt_phase_pointer_enable(struct drm_device *dev, int pipe) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
