[Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.
With Haswell, 5.4Gbps is supported. And almost all of the code was
already in place already. All that was missing was this tiny bit of
additional wiring.
Signed-off-by: Carl Worth cwo...@cworth.org
Reviewed-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 57552eb..ce9739e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -101,7 +101,11 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp)
case DP_LINK_BW_1_62:
case DP_LINK_BW_2_7:
break;
- case DP_LINK_BW_5_4: /* 1.2 capable displays may advertise higher bw */
+ case DP_LINK_BW_5_4:
+ /* XXX: But not HASWELL ULX. */
+ if (IS_HASWELL(intel_dp_to_dev(intel_dp)))
+ break;
+ /* Prior to HASWELL, maximum support is for 2.7 Gbps */
max_link_bw = DP_LINK_BW_2_7;
break;
default:
@@ -810,12 +814,24 @@ intel_dp_compute_config(struct intel_encoder *encoder,
enum port port = dp_to_dig_port(intel_dp)-port;
struct intel_crtc *intel_crtc = encoder-new_crtc;
struct intel_connector *intel_connector = intel_dp-attached_connector;
- int lane_count, clock;
+ int lane_count;
int max_lane_count = drm_dp_max_lane_count(intel_dp-dpcd);
- int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 :
0;
int bpp, mode_rate;
- static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
int link_avail, link_clock;
+ int max_link_bw;
+ /* The clock and max_clock values are an index into bws. */
+ int clock, max_clock = 0;
+ static int bws[3] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7, DP_LINK_BW_5_4};
+
+ max_link_bw = intel_dp_max_link_bw(intel_dp);
+
+ for (clock = 0; clock ARRAY_SIZE(bws); clock++) {
+ if (bws[clock] == max_link_bw) {
+ max_clock = clock;
+ break;
+ }
+ }
+
if (HAS_PCH_SPLIT(dev) !HAS_DDI(dev) port != PORT_A)
pipe_config-has_pch_encoder = true;
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Refuse to load driver for depth-8 X server.
The driver is not functional at this depth, so tell the user as much and
bail out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31375
---
src/intel_driver.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/intel_driver.c b/src/intel_driver.c
index 7807106..7f11978 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -532,15 +532,15 @@ static Bool I830PreInit(ScrnInfoPtr scrn, int flags)
return FALSE;
switch (scrn-depth) {
- case 8:
case 15:
case 16:
case 24:
case 30:
break;
+ case 8:
default:
xf86DrvMsg(scrn-scrnIndex, X_ERROR,
- Given depth (%d) is not supported by I830 driver\n,
+ Given depth (%d) is not supported by intel
driver\n,
scrn-depth);
return FALSE;
}
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Error state should print /sys/kernel/debug
Ben Widawsky b...@bwidawsk.net writes: /sys/kernel/debug has more or less been the standard location of debugfs for several years now. Other parts of DRM already use this location, so we should as well. Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Carl Worth cwo...@cworth.org -Carl pgpygWO4962Aw.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't forget to apply SNB PIPE_CONTROL GTT workaround.
Eric Anholt e...@anholt.net writes: I have not tested it yet, but hopefully when cworth gets home he will. Reviewed-by: Carl Worth cwo...@cworth.org Tested-by: Carl Worth cwo...@cworth.org Thanks, Eric! This is perfect. -Carl -- carl.d.wo...@intel.com pgp0yyvRoVr80.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] configure: updated m4 macro check in configure.ac
On Tue, 21 Dec 2010 15:10:41 -0700, U. Artie Eoff ullysses.a.e...@intel.com wrote: Added m4 check for XORG_DRIVER_CHECK_EXT macro definition. Updated m4 fatal messages to give better hint on how to resolve error when xorg macros are missing. Previously, configure would continue in spite of the missing macros and the build would fail for syntax errors. Thanks so much, Artie! I've now pushed this change out. Only just after pushing it did I notice that the commit message is all one long line. No big deal for this commit, but in future commits, if you wrap that paragraph to fit within 80 columns then some tools will display the commit message more cleanly. Thanks again, -Carl -- carl.d.wo...@intel.com pgpBNXnLiPYMX.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [ANNOUNCE] xf86-video-intel snapshot: 2.13.901
This is an intermediate snapshot of ongoing driver development. The primary purpose of this snapshot is to capture some recent improvements, (particularly in Sandybridge support), for further testing. As always, we look forward to any results from testing. Thank you, -Carl -- carl.d.wo...@intel.com Where to obtain xf86-video-intel 2.13.901 - git tag: 2.13.901 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.901.tar.bz2 MD5: 2bd3650038acff7ff63a3efdf7f61dae xf86-video-intel-2.13.901.tar.bz2 SHA1: fb28742261b6196b936edbfd45e993030e31706c xf86-video-intel-2.13.901.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.901.tar.gz MD5: 0477b9b42b4e1643fefd66332e6d1f39 xf86-video-intel-2.13.901.tar.gz SHA1: 94936851432d622dd05158ee91724106301ad6ef xf86-video-intel-2.13.901.tar.gz Log of changes from 2.13.0 to 2.13.901 -- Adam Jackson (1): intel: Listen for hotplug uevents (V3) Carl Worth (2): NEWS: Add release notes for 2.13.901 snapshot. Update version number to 2.13.901 Chris Wilson (26): video: Disable TextureAdaptor for Sandybridge legacy/i810: Remove pVisualConfigs Do not claim the PCI device if !KMS Split shadow handling routines to their own file. shadow: Map the scanout directly on i8xx shadow+dri2: Allow dri2 to be independently enabled with shadow shadow: Disable BLT for SandyBridge shadow: Enable shadow by default on SandyBridge shadow: Use a cacheable shadow for all generations Clear pixmap-devPrivate.ptr [regression from 7c7294e] Revert Clear pixmap-devPrivate.ptr [regression in 7c7294e] uxa: Re-enable acceleration. uxa: Skip a pixmap lookup if there is no driver finish access function dri: Reattach the fake pixmap for the shadow scanout to the drawable. dri+shadow: Only tweak the acceleration of CopyRegion if using shadow. Include a chipset generation number to clarify device specific paths. dri: Check for pixmap privates before dereferencing them Move EDID_COMPLETE_RAWDATA define to intel.h to avoid redifinition warning Fix driverName regression for i830 from 4083197a display: do not report failure for setting unrecognised properties uxa: Enable reduced fence sizes for i915 intel: don't pass a dangling pointer to GET_PARAM Flush BLT batches before starting an atomic RENDER batch Fallback to shadow for Sandybridge if we don't have access to the BLT Downgrade tiling allocation failure to a warning Wait for any pending rendering before switching modes. Eric Anholt (2): Fix violation of gen6 requirements for depthbuffer tiling. Remove the intermittent GEM_THROTTLE call. Stefan Dirsch (1): Make driver compile for 1.6 Xserver series again. Part deux. Xiang, Haihao (11): Xv: set the surface state base address Xv: Send instruction doesn't use implied move when sampling YUV surface Xv: fragments for xv on Sandybridge. Xv: setup pipeline for Xv on Sandybridge Xv: enable TextureAdaptor for Sandybridge Xv: don't call intel_wait_for_scanline on Sandybridge render: set the surface state base address render: fix send instruction used in sampling fragments render: fragments for composite on Sandybridge render: acceleration for composite on Sandybridge render: use headerless render target write Zhenyu Wang (1): Always use tiling on Sandybridge Zou Nan hai (2): add BLT ring support Support BLT acceleration on gen6 pgpEFYmLmi2oq.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [bisected] commit 176f28eb breaks my Sandybridge
The commit below causes my Sandybridge system to fail at initial KMS
initialization:
Aug 27 18:58:04 livid kernel: [9.099032] i915 :00:02.0: irq 42 for MSI/M
SI-X
Aug 27 18:58:04 livid kernel: [9.099086] [drm:init_ring_common] *ERROR*
render ring initialization failed ctl head tail
start
Aug 27 18:58:04 livid kernel: [9.099266] [drm:i915_driver_load] *ERROR*
failed to init modeset
Aug 27 18:58:04 livid kernel: [9.110257] PM: Removing info for No Bus:card0
Aug 27 18:58:04 livid kernel: [9.110304] PM: Removing info for No
Bus:controlD64
Aug 27 18:58:04 livid kernel: [9.110326] i915: probe of :00:02.0 failed
with error -5
[Ignore the date/time---that really was from a boot today.]
Chris, what can I do to help debug what the correct solution is here?
-Carl
commit 176f28ebf4303b4f7e3a5bd8be7842a8bbecd9c3
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu Oct 28 11:18:07 2010 +0100
drm/i915/ringbuffer: Check that we setup the ringbuffer
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/inte
index 8eaa60c..e88214e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -176,9 +176,10 @@ static int init_ring_common(struct intel_ring_buffer *ring)
((ring-gem_object-size - PAGE_SIZE) RING_NR_PAGES)
| RING_NO_REPORT | RING_VALID);
- head = I915_READ_HEAD(ring) HEAD_ADDR;
/* If the head is still not zero, the ring is dead */
- if (head != 0) {
+ if ((I915_READ_CTL(ring) RING_VALID) == 0 ||
+ I915_READ_START(ring) != obj_priv-gtt_offset ||
+ (I915_READ_HEAD(ring) HEAD_ADDR) != 0) {
DRM_ERROR(%s initialization failed
ctl %08x head %08x tail %08x start %08x\n,
ring-name,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [bisected] commit 176f28eb breaks my Sandybridge
On Thu, 04 Nov 2010 23:41:45 +, Chris Wilson ch...@chris-wilson.co.uk wrote: Find a hw engineer, and ask him nicely why his ringbuffer registers return 0 *most* of the time. Ugh. Having the error there was to make sure people noticed and I could find out just how many SNB revisions failed. I presume you have a rev 8? Yes, rev 8 here. -Carl -- carl.d.wo...@intel.com pgpPCyHVx03Ku.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.13.0
We are pleased to announce this major release of the xf86-video-intel driver, on schedule at 3 months since 2.12.0. With the many bug fixes in this release, we encourage everyone using 2.12 to upgrade to 2.13. [This release is functionally identical to the earlier 2.12.902 release candidate.] -Carl Where to obtain xf86-video-intel 2.13.0 --- git tag: 2.13.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.0.tar.bz2 MD5: de2f8a5836d90c71f3175dcd46d03ec0 xf86-video-intel-2.13.0.tar.bz2 SHA1: 1b2aebd444bcfc371a55af8910eb4d5928eab5c9 xf86-video-intel-2.13.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.13.0.tar.gz MD5: df7e3644a34e97ead09f083ab48d4457 xf86-video-intel-2.13.0.tar.gz SHA1: 280599540b3fecdac45a1c37ec5116e922ce698e xf86-video-intel-2.13.0.tar.gz New requirements compared to 2.12 - * Librdrm = 2.4.22 Notable bug fixes - * Attempt to fix infinite MI_WAIT_FOR_EVENT while watching video https://bugs.freedesktop.org/show_bug.cgi?id=28964 [Various new checks have been added to the video code here, but the bug fix hasn't yet been verified by the original reporter.] * Fix buffer-object leak https://bugs.freedesktop.org/show_bug.cgi?id=26946 * Fix memory leak on server reset * Fix crash due to unchecked pixmap allocation https://bugs.freedesktop.org/show_bug.cgi?id=29187 * Fix for video artifacts when using dualscreen https://bugs.freedesktop.org/show_bug.cgi?id=29213 * Fix for incorrect characters in gnome-terminal when using compiz https://bugs.freedesktop.org/show_bug.cgi?id=28438 * Fix for hanging, full-screen applications, (flash, compiz, etc.) https://bugs.freedesktop.org/show_bug.cgi?id=29584 * Fix selection of backlight device on multi-GPU systems https://bugs.freedesktop.org/show_bug.cgi?id=29273 * Fix to avoid crash with extremely large glyphs https://bugs.freedesktop.org/show_bug.cgi?id=29430 * Fix for eDP panels incorrectly being given only a single, valid mode https://bugs.freedesktop.org/show_bug.cgi?id=30069 * Fix GPU hang involving clipped SRC copies https://bugs.freedesktop.org/show_bug.cgi?id=30120 * Fix to compile for 1.6 series X server. * Fix to retry framebuffer allocation after an initial failure. * Fix to disable dri2 after fallbacks are forced on. All changes from 2.12.0 to 2.13.0 - Carl Worth (7): NEWS: Add notes for the 2.12.901 snapshot Bump version to 2.12.901 Fix to depend on the (just-released) libdrm = 2.4.22 Add release notes for the 2.12.902 snapshot. Increment version to 2.12.902 Add release notes for the 2.13.0 release. Increment version to 2.13.0 Chris Wilson (57): Remove unused configure option: --enable-video-debug i810: Move into a legacy directory. Rename common infrastructure to the intel namespace. configure: Remove unused checks for xext configure: Remove check for unused function, mprotect Remove unused inclusion of sys/mman.h Repair the damage to 'make distcheck' after splitting out i810 dri: Handle errors during GetBuffers() gracefully. drmmode: Use a copy of the converted mode on resize drmmode: Add missing newlines at the end of log messages. Reduce front buffer stride prior to rejection video: apply the crtc box checks from dri. video: forgotten amendment to previous commit. Add support for I854. drmmode: Destroy Crtc on screen shutdown drmmode: Destroy the output on shutdown video: Copy DummyEncoding into each adapter. video: Apply overlay stride errata for i830 and i845 modes: There may be more than one crtc and output... DESTROY THEM ALL! Remove the duplicate drmmode prototypes. Teardown the bufmgr on shutdown as well. Workaround a broken container_of define in list.h video: Reuse the old buffers. video: Free the buffers immediately after turning off. uxa: Check for failed pixmap allocation video/i915: ValidateGC after setting clip. drmmode: Only treat a backlight as connected if it has a non-zero max Rename drmmode_display to intel_display intel_display: Miscellaneous tidy Remove the final references to the drmmode prefix display: Check for buffer overrun in output name lookup. display: Tidy backlight initialisation display: Handle cursor error paths. display: Embed the lvds size into the connector display: Cache whether we have probed for an EDID Revert display: Cache whether we have probed for an EDID display: Refactor EDID attachment to output. display: Minor cleanup for adding extra LVDS modes display: outputs are enabled automatically by KMS Move registration of vsync fd from pre-init to screen-init Open-code
[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.12.902
This is the second release candidate in preparation for the upcoming 2.13.0 release. This comes exactly one week after 2.12.902 and includes only a handful of changes. One significant change is that the driver now requires libdrm 2.4.22 (or newer), as several people reported compilation failures of xf86-video-intel 2.12.901 with libdrm 2.4.21. Other changes include a fix to compile for the 1.6 series X server, a fix to retry framebuffer allocation after an initial failure, and a fix to disable dri2 after fallbacks are forced on. -Carl Where to obtain xf86-video-intel 2.12.902 - git tag: 2.12.902 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.12.902.tar.bz2 MD5: 995ae6d19f466f3e69f0c59816898cf5 xf86-video-intel-2.12.902.tar.bz2 SHA1: 2ffc34923d29cb77a698862fd40d51931a77403d xf86-video-intel-2.12.902.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.12.902.tar.gz MD5: 243c8a4ee23376fcfae49e9028120910 xf86-video-intel-2.12.902.tar.gz SHA1: 19070c310de69b3aad179afe54a3068e2926492d xf86-video-intel-2.12.902.tar.gz All changes from xf86-video-intel 2.12.901 to 2.12.902 -- Carl Worth (3): Fix to depend on the (just-released) libdrm = 2.4.22 Add release notes for the 2.12.902 snapshot. Increment version to 2.12.902 Chris Wilson (3): display: Refactor is_panel() Disable dri2 after forcing fallbacks Retry framebuffer allocation if first attempt fails. Matthias Hopf (1): Make driver compile for 1.6 Xserver series again. -- carl.d.wo...@intel.com pgpImCMjMP95A.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.11.901
On Thu, 17 Jun 2010 18:34:43 -0300, Elias Gabriel Amaral da Silva tolkiend...@gmail.com wrote: 2010/6/15 Carl Worth cwo...@cworth.org: Hello! I'm, maybe, getting the same thing here. I haven't tested the release candidate, but with Xorg 1.8 and driver 2.11, and a kms-enabled 2.6.34 kernel, using gentoo, X just freezes. If I downgrade it to 2.9 driver and 1.7 Xorg, it runs (but if I do USE=hal at Xorg, it freezes, too). Hi there, Elias! I have an Acer 532h (Intel GMA 3150, afaik). I've read your explanation on how to do git bisecting and it sounds easy. Good. It really should be quite simple. I should test with a fixed Xorg version, right? Which one? Portage currently has this: 1.6.5-r1 1.7.6 ~1.7.7 ~1.8.0 ~1.8.1-r1 Before you can bisect, you'll want to identify a single component that exposes the bug. Above you described a change of two components, (both X server and driver), to switch from a broken to a working configuration. So the first thing to do is to try keeping the X server version fixed and see if changing the driver alone changes the behavior. I haven't tried driver 2.9 with xorg 1.8, because I supposed newer xorg versions were incompatible with old drivers.. I'd actually recommend using the newer X in both cases. I would hope that new X would work fine with an older driver, (but there might be some point at which the driver really is *too old* for a particular X server). In that case, you might need to bump the driver version up and hope that it still works. Good luck! And thanks in advance for any future information you might be able to provide. -Carl -- carl.d.wo...@intel.com pgpJA9TCuoeDW.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Patch review
On Sun, 25 Apr 2010 22:48:18 -0400, Matt Turner matts...@gmail.com wrote: I've got a similar experience--I actually had two patches /accepted/ and supposedly tucked away in a branch for merging after 2.11 was released. They've never been merged. I've pinged Carl at least twice, heard nothing back. Not sure what's going on. Hi Matt, That was entirely my fault. The patches are still there on my after-2.11 branch. And after your most recent ping I did try to merge them and found that they now conflict. I'm sorry about that. I can try to resolve the conflicts, but I will likely want your final review of the result. -Carl -- carl.d.wo...@intel.com pgpC2eLd3zmm1.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
