pci.ids and the datasheet both say it's 358e, not 35e8.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/i915_drv.c |5 +++--
drivers/gpu/drm/i915/i915_drv.h |3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b
On Fri, 2010-04-16 at 10:24 +0800, ykzhao wrote:
On Fri, 2010-04-16 at 02:03 +0800, Adam Jackson wrote:
IS_MOBILE() catches 85x, so we'd always try to use the 9xx FIFO sizing;
since there's an explicit 85x version, this seems wrong.
Right. It seems that the incorrect get_fifo_size callback
/584229
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_bios.c |1 +
drivers/gpu/drm/i915/intel_sdvo.c | 41
3 files changed, 11 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu
On Mon, 2010-04-26 at 23:24 +0100, Peter Clifton wrote:
---
drivers/gpu/drm/i915/intel_display.c | 38 ++---
drivers/gpu/drm/i915/intel_drv.h |2 +-
2 files changed, 17 insertions(+), 23 deletions(-)
Nak.
This will break DirectColor visuals in X.
On Tue, 2010-04-27 at 14:16 -0500, Gabriel M. Beddingfield wrote:
On Tue, 27 Apr 2010, Adam Jackson wrote:
On Tue, 2010-04-27 at 12:53 -0500, Gabriel M. Beddingfield wrote:
Any idea why it won't load the correct resolution?
Because you're using the vesa driver, and you should be using
On Wed, 2010-04-28 at 10:15 +0800, Zhenyu Wang wrote:
On 2010.04.23 16:16:12 -0400, Adam Jackson wrote:
Multifunction SDVO cards stopped working after 14571b4, and would report
something that looked remarkably like an ADD2 SPD ROM instead of EDID.
This appears to be because DDC bus
On Wed, 2010-05-05 at 10:52 -0700, Carl Worth wrote:
I'm going through the past couple weeks of traffic on the list looking
for patches that haven't gotten picked up yet.
So I'd love to review one like this, but it would be easier if the
commit message pointed me to something specific I
On Thu, 2010-05-13 at 10:46 +0800, Zhenyu Wang wrote:
On 2010.05.12 11:29:53 -0400, Adam Jackson wrote:
eDP panels are often fixed-rate. Grab the link speed and lane count
from the VBT and use those instead of trying to compute them.
Signed-off-by: Adam Jackson a...@redhat.com
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 78a75e8..a1a6785 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b
DisplayPort spec v1.1a, Table 2-52.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 77e40cf..78a75e8 100644
On Mon, 2010-05-17 at 12:13 +0100, Simon Farnsworth wrote:
The first bit of misbehaviour I'm seeing is caching of EDID across hotplug
events. If I boot my system with no display attached, I correctly see no EDID
property. When I connect a monitor via VGA, using cabling that supports DDC, I
On Tue, 2010-05-18 at 18:07 +0100, Simon Farnsworth wrote:
On Tuesday 18 May 2010, Adam Jackson a...@redhat.com wrote:
On Mon, 2010-05-17 at 12:13 +0100, Simon Farnsworth wrote:
The first bit of misbehaviour I'm seeing is caching of EDID across
hotplug events. If I boot my system
Disable the CRT plug interrupt while doing the force cycle, explicitly
clear any CRT interrupt we may have generated, and restore when done.
Should mitigate interrupt storms from hotplug detection.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/i915_reg.h |1 -
drivers
On Mon, 2010-05-24 at 21:46 -0400, Andrew Lutomirski wrote:
On Mon, May 24, 2010 at 4:46 PM, Adam Jackson a...@redhat.com wrote:
Disable the CRT plug interrupt while doing the force cycle, explicitly
clear any CRT interrupt we may have generated, and restore when done.
Should mitigate
of that.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/i915_irq.c | 50 ++-
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a7e4b1f..f9d2cc0 100644
I'm actually kind of shocked that it works at all otherwise.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_bios.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
On Thu, 2010-05-27 at 17:26 -0400, Adam Jackson wrote:
Unmask, then enable interrupts, then enable interrupt sources; matches
PCH ordering. The old way (sources, enable, unmask) gives a window
during which interrupt conditions would appear in ISR but would never
reach IIR and thus never raise
On Fri, 2010-06-04 at 10:40 -0500, Sander Jansen wrote:
When will the GMA HD reference docs become available?
If you mean Core i3/i5 (Ironlake), then:
http://www.x.org/docs/intel/HD/
- ajax
signature.asc
Description: This is a digitally signed message part
On Mon, 2010-06-07 at 16:41 +, bob schulman wrote:
Use of this function seems central for server-space use of DRI (as
this function sets up the DRIScreenPrivKey for use by dixLookupPrivate
by way of dixSetPrivate()). Yet this func is only called by
I810DRIScreenInit() which is only called
On Tue, 2010-06-29 at 16:44 +0800, Zhenyu Wang wrote:
On 2010.06.28 14:04:56 +0800, Zhenyu Wang wrote:
sorry, this is still broken on the 16x9 panel.
'intel_dp_link_required' is 107840*18/8 = 242640, 'intel_dp_max_data_rate'
is
27*1*8/10 = 216000. So it will fail in both
On Fri, 2010-07-02 at 16:43 -0400, Adam Jackson wrote:
Worst dotclock for Ironlake DAC refclk is 35kHz (error 0.00571)
Worst dotclock for Ironlake SL-LVDS refclk is 102321kHz (error 0.00524)
Worst dotclock for Ironlake DL-LVDS refclk is 219642kHz (error 0.00488)
Worst dotclock
On Tue, 2010-07-13 at 10:02 +0100, Julien Cristau wrote:
On Tue, Jul 13, 2010 at 16:29:37 +1000, Huaxin Xu wrote:
Hi,
My X windows application shows some funny lines after being launched.
Please find kernel .config, Xorg.conf and Xorg.log in the attachments.
Setup: Desktop,
On Thu, 2010-07-15 at 11:54 +1000, Huaxin Xu wrote:
Thanks for the info!
A follow-up question: is G41 support in every kernel after
2.6.27-stable? In particular, is it in 2.6.31.5-127?
Yes.
- ajax
signature.asc
Description: This is a digitally signed message part
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b4f0282..c2b3d9b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
On Fri, 2010-07-23 at 16:29 -0400, Andrew Lutomirski wrote:
Does that include not breaking DirectColor? If we program the gamma
ramp to 129 slots, old userspace submits 256 entries that are not
monotonic, and we decimate the gamma ramp, we'll display the wrong
thing. I have no idea if there
On Thu, 2010-08-05 at 11:53 +1000, Dave Airlie wrote:
So I've been reviewing the i915/ironlake CRT detect code and am a bit
confused.
I though on the i945 and above that we had proper CRT hotplug
detection with an IRQ, that didn't require any polling.
Now looking at the code when we do a
On Sat, 2010-08-07 at 11:13 +0200, Alexey Fisher wrote:
Seems like totem (video player) re ask every time for new hardware or
some thing like this. i can't reproduce it with mplayer.
My question is, is it the right way to do? are they any thing wrong
about it?
They shouldn't be reprobing
On Wed, 2010-08-11 at 10:25 +0100, Chris Wilson wrote:
To simplify the IS_GEN[234] macros and to enable switching.
I think your three cent titanium tax doesn't go too far enough.
830, 845g, 85x, and 865 all now have
.gen = 2,
.is_i8xx = 1,
and nothing later has .is_i8xx, so that field
On Fri, 2010-08-13 at 16:03 -0700, Jesse Barnes wrote:
We need to use I/O port instructions to access VGA registers on
Ironlake+, and it doesn't hurt on other platforms, so switch the VGA
plane disable function over to using them. Move it to init time as well
while we're at it, no need to
On Mon, 2010-08-16 at 10:27 -0400, Andy Lutomirski wrote:
But that's really the problem, because intel_sdvo_dvi_init contains:
connector-polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
I don't know if SDVO is supposed to send hotplug interrupts because
that
On Sun, 2010-08-22 at 19:06 +0100, Chris Wilson wrote:
On Sun, 22 Aug 2010 18:23:21 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
My Samsung N210 has a VBT with DEVICE_TYPE_INT_LFP with a zero
addin-offset. With the check in place, the panel was declared absent.
Reviewing the
On Fri, 2010-08-27 at 12:19 +0200, Andreas Heider wrote:
Hello everyone,
at the moment i'm trying to get vga_switcheroo working on a 2010
macbook pro. This laptop has two graphics cards, a dedicated nvidia
one and an integrated intel arrandale chip. Switching is still pretty
rough but it kind
On Mon, 2010-08-30 at 18:47 +, The Fungi wrote:
On Mon, Aug 30, 2010 at 02:19:23PM -0400, Adam Jackson wrote:
Pretty sure parse-edid doesn't understand CEA extension blocks. The
kernel does though.
Aha--that probably explains it. Are there any userspace alternatives
to parse-edid
On Tue, 2010-08-31 at 01:12 +, The Fungi wrote:
On Mon, Aug 30, 2010 at 02:56:26PM -0400, Adam Jackson wrote:
git clone git://anongit.freedesktop.org/xorg/app/edid-decode
I try to keep that reasonably up to date, though it's lagging a little.
Do let me know if you have patches
On Tue, 2010-08-31 at 14:19 +, The Fungi wrote:
On Tue, Aug 31, 2010 at 09:49:53AM -0400, Adam Jackson wrote:
It's possible but improbable. What kernel are you running anyway?
That system had 2.6.35-rc5 i686 with PAE at the last boot (needed
some patches for Wacom BT/HID support which
On Fri, 2010-08-27 at 12:19 +0200, Andreas Heider wrote:
Hello everyone,
at the moment i'm trying to get vga_switcheroo working on a 2010
macbook pro. This laptop has two graphics cards, a dedicated nvidia
one and an integrated intel arrandale chip. Switching is still pretty
rough but it
diagnosed.
I've seen more than one machine where LVDS comes up on pipe A from BIOS,
so this will necessitate a DPMS cycle when loading the KMS driver.
Oh well.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message part
Wang zhen...@linux.intel.com
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
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
scrn-currentMode is a hack for xf86vidmode and in general is wrong for
RANDRful drivers. Use the mode on the associated CRTC instead.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/intel_video.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/intel_video.c b
scrn-currentMode is a hack for xf86vidmode and in general is wrong for
RANDRful drivers. Use the mode on the associated CRTC instead.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/intel_dri.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/intel_dri.c b
Since, with GPU-on-package, it's hard to talk about a model number for
a specific chipset like 855GM, just use the platform names.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/i965_render.c |6 +++---
src/i965_video.c |4 ++--
src/intel_driver.h | 28
On 5/5/11 5:42 PM, Jesse Barnes wrote:
FBC has too many corner cases that we don't currently deal with, so
disable it by default so we can enable more important features like RC6,
which conflicts in some configurations.
Signed-off-by: Jesse Barnesjbar...@virtuousgeek.org
It's a bit weird to
On 5/8/11 2:22 PM, Knut Petersen wrote:
Software
===
1.86 MHz system:
opensuse 11.2
X.Org X Server 1.6.5
Release Date: 2009-10-11
kernel 2.6.38.5
2.00 MHz system:
opensuse 11.4
X.Org X Server 1.10.99
git-tree, 2011-may-7
kernel 2.6.39-rc4-drm-intel-staging
I'd start by suspecting
Signed-off-by: Adam Jackson a...@redhat.com
---
src/intel_driver.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/intel_driver.c b/src/intel_driver.c
index b79f8c9..8666421 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -84,7 +84,6 @@ USE OR OTHER
On Wed, 2011-05-11 at 09:52 -0700, Jesse Barnes wrote:
+ /*
+ * On Ibex Peak and Cougar Point, we need to disable clock
+ * gating for the panel power sequencer or it will fail to
+ * start up when no ports are active.
+ */
Nitpick: Probably either this comment (and
On Wed, 2011-05-11 at 10:26 -0700, Jesse Barnes wrote:
On Wed, 11 May 2011 13:20:55 -0400
Adam Jackson a...@redhat.com wrote:
Nitpick: Probably either this comment (and its mate in
gen6_init_clock_gating) should just refer to PCH generically if this is
going to keep being true
On Wed, 2011-05-11 at 16:46 +0200, Knut Petersen wrote:
Yes, I made some mistakes during my first measurements.
Below find better results. They are made on the same machine,
with the same kernel, at the same speed, with the same x11perf
program, absolutely nothing changed.
You don't mention
On Wed, 2011-05-11 at 23:22 +0200, Knut Petersen wrote:
Yes, there is
15400.00.54 GetProperty
15500.00.54 QueryPointer
but we also see
815.01.21 X protocol NoOperation
NoOp isn't a round trip, it does not generate a reply. That test
measures how fast
On 5/18/11 9:41 AM, Florian Mickler wrote:
Since
commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jacksona...@redhat.com
Date: Fri Jul 16 14:46:29 2010 -0400
drm/i915: Initialize LVDS and eDP outputs before anything else
my xserver chooses a wrong resolution for my VGA
On 6/1/11 6:06 AM, Florian Mickler wrote:
Recently the kernel started reporting my outputs in a different ordering due to
commit cb0953d734
(drm/i915: Initialize LVDS and eDP outputs before anything else)
Which made X choose a wrong resolution for my VGA display. Since they are
On 6/1/11 4:44 PM, Florian Mickler wrote:
I think using horizontal spanning as a default is a good idea.
Also bringing all outputs up in their preferred mode could be the right
move.
[That commit in question wouldn't help my case, since I have a Right Of in the
xorg.conf and thus it would use
I have no evidence for this byte being used this way, and lots of
counterexamples. Restore the struct to its empirical definition and
patch up gmbus setup to match.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_bios.c
I can't think of any sensible reason to limit this to a mask of 0x0f,
ie, SDVO_OUTPUT_{TMDS,RGB,CVBS,SVID}0.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_sdvo.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
This is general TMDS detect, not HDMI specifically.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_sdvo.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 475f615
The comment was wrong, bus 0 is the SPD ROM, as we discovered in
14571b4 and b108333.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_sdvo.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu
It's not wrong, but the text and the code describe different predicates
and my brain kept stumbling over it.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_sdvo.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_i2c.c |8 +---
drivers/gpu/drm/i915/intel_sdvo.c |2 +-
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d3b903b..5d707c4
I'd like it to not be in the SDK anymore, and we're not using anything
from it.
Signed-off-by: Adam Jackson a...@redhat.com
---
src/intel_dri.c|1 -
src/intel_driver.c |1 -
src/legacy/i810/i810_dri.c |1 -
src/sna/sna_dri.c |1 -
src/sna/sna_driver.c
Patch 1 is actually core drm, and independent of the rest of the series.
The rest vary among cosmetic cleanup, unifying the G4X/IRL paths, and
one corner-case change to be more strictly spec-compliant.
Tested on a Thinkpad T500 (GM45) with various DisplayPort attachments.
My X200 (with DP only on
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e2aced6..de24f31 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b
No reason not to see this on g4x, after all.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index de24f31..0be85a0
For parity with radeon and nouveau, and also because I suspect we're
going to need it to get format-conversion dongles right.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers
%hx alone prints 0 as 0, not 00.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2f0566b..13bddd3 100644
It's not clear what a sink would do if you wrote zero to this register -
which I guess would mean I don't support any channel encodings, good
luck - but let's not find out.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c |1 +
1 files changed, 1 insertions
above, if 'width' comes out even,
rounding down is correct; if it's odd, you'd rather round up. So just
increment width/height in those cases.
Tested on a Lenovo T500 (Ironlake).
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_panel.c |4
1 files changed, 4
in the log.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7af1f24..a449d96 100644
--- a/drivers/gpu/drm
The DP spec says training patterns 1 and 2 are to be sent non-scrambled,
and the GPU docs claim that happens (or at least, there's no explicit
scrambling control). But the sink may be confused if we don't
explicitly tell it what we're doing, so play it safe.
Signed-off-by: Adam Jackson
places where the
DPCD block was read from the device. Now everyone shares the same
function, and that function retries the reads.
Reviewed-by: Adam Jackson a...@redhat.com
[PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code
I was experimenting with DP hotplugging -- moving
The default in the Sandybridge docs is 5, as on Ironlake, and I have no
reason to believe 3 would work any better.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915
Not, we hope, that it ever fails.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_opregion.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index b8e8158b..ef00a7d
@ajax mjg59: how concerned should i be about [drm:intel_dsm_pci_probe]
*ERROR* failed to get supported _DSM functions ?
@mjg59 ajax: Entirely unconcerned
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_acpi.c |2 +-
1 files changed, 1 insertions(+), 1
to get comments back
in a day or so.
I've not had the opportunity to test this yet, but the code certainly
looks plausible, and not having HPD on SDVO is just lame.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
Intel-gfx mailing list
Intel-gfx
On Thu, 2011-06-16 at 16:36 -0400, Adam Jackson wrote:
I have no evidence for this byte being used this way, and lots of
counterexamples. Restore the struct to its empirical definition and
patch up gmbus setup to match.
Signed-off-by: Adam Jackson a...@redhat.com
This code is still present
Just a few things spotted in a readthrough. The DPLL disable one might
actually be a bugfix, who knows.
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b73150f..9edf363 100644
--- a/drivers/gpu/drm/i915
All gen5+ parts are PCH (so far anyway), so just say so.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_display.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 67dbe22..3e4f25d 100644
--- a/drivers/gpu/drm/i915
On Tue, 2011-09-13 at 14:11 -0400, Adam Jackson wrote:
@ajax mjg59: how concerned should i be about [drm:intel_dsm_pci_probe]
*ERROR* failed to get supported _DSM functions ?
@mjg59 ajax: Entirely unconcerned
Signed-off-by: Adam Jackson a...@redhat.com
Anybody? This makes quiet
This fixes a rather irritating limitation of active dp-foo converters.
Many such (including all DP-VGA chips I can find on the market) come
equipped with only 2 DP lanes, which clips your dotclock to 144MHz at
8bpc. Of the standard DMT modes, that means you lose 1600x1200@60 and
above. Since
Shouldn't hide these behind _DRIVER, they're all KMS-related.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
Some active adaptors (VGA usually) only have two lanes at 2.7GHz.
That's a maximum pixel clock of 144MHz at 8bpc, but 192MHz at 6bpc.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_display.c | 22 --
drivers/gpu/drm/i915/intel_dp.c | 31
On Mon, 2011-10-10 at 14:28 -0700, Jesse Barnes wrote:
It's needed for 3 pipe support as well as just regular functionality
(e.g. DisplayPort).
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Tested-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description
On 10/11/11 4:59 AM, Daniel Vetter wrote:
... not DISPLAY_VGA, because we ignore the VGA subclass with our
class_mask.
It confused me until Chris Wilson clued me up.
Signed-off-by: Daniel Vetterdaniel.vet...@ffwll.ch
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
On 10/10/11 7:22 PM, Keith Packard wrote:
On Mon, 10 Oct 2011 14:28:52 -0700, Jesse Barnesjbar...@virtuousgeek.org
wrote:
It's needed for 3 pipe support as well as just regular functionality
(e.g. DisplayPort).
Any explanation on how you get sync without this? As in, why did this
ever
.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 10/11/11 12:16 PM, Jesse Barnes wrote:
On Tue, 11 Oct 2011 10:10:24 -0400 Adam Jacksona...@redhat.com wrote:
It still seems entirely magical and probably wrong in some situations.
And I'm thrilled to see that PPT is functionally different from CPT
(seriously, stop doing that) instead of
On Wed, 2011-10-12 at 11:12 -0700, Jesse Barnes wrote:
The cursor regs have moved around, add the offsets and new macros for
getting at them.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Tested-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally
On Thu, 2011-10-13 at 09:49 -0300, przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Fixes fd.o #41272
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description: This is a digitally signed message
On Thu, 2011-10-13 at 15:11 -0300, Eugeni Dodonov wrote:
diff --git a/drivers/gpu/drm/i915/intel_i2c.c
b/drivers/gpu/drm/i915/intel_i2c.c
index d98cee6..b3a6eda 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -470,3 +470,45 @@ void
The previous code was confused about units, which is pretty reasonable
given that the units themselves are confusing.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 26 +-
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git
These were just working around the math being wrong.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
The obvious counterpart to is_pch_edp(). Convert existing instances of
the idiom to the new routine.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
According to the gen6 docs, only the DP_A port (on-CPU eDP) still uses
the old IBX bit shift for the link training pattern setup bits.
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/i915/intel_dp.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git
On Fri, 2011-10-14 at 23:11 -0700, Keith Packard wrote:
On Fri, 14 Oct 2011 12:43:49 -0400, Adam Jackson a...@redhat.com wrote:
The previous code was confused about units, which is pretty reasonable
given that the units themselves are confusing.
Thanks for actually figuring this out
consistent with the workaround for CPT provided by the
hardware team. This patch helped catch the fact that the pipe wasn't
running in the !composite sync FDI case on my IVB SDV, so has already
shown to be useful.
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
Description
(the compliance testing one at least) happier.
I can re-post or you can just commit this by itself. Any preference?
Sorry to be late on this one. Matches the 1.1a spec (well, to the
extent that 1.1a says anything with authority).
Reviewed-by: Adam Jackson a...@redhat.com
- ajax
signature.asc
On Wed, 2011-10-19 at 17:48 +0400, 4ernov wrote:
Thanks, Adam. But is there any pipe setup part specific for certain
output? I need to find a place where converter is set to use 24 or 18
bit LVDS mode. I examined intel_sdvo.c quite long but still cannot
find what I want.
We don't appear to
On Wed, 2011-10-19 at 18:43 +0400, 4ernov wrote:
And is it guessed somewhere in case of VBT missing?
Well, not yet, no. Like I said, there's no code at all yet for tweaking
SDVO LVDS.
In my case there's
no OpRegion support (i945GME chipset don't support it as mainboard
manufacturer
On Mon, 2011-10-10 at 16:33 -0400, Adam Jackson wrote:
This fixes a rather irritating limitation of active dp-foo converters.
Many such (including all DP-VGA chips I can find on the market) come
equipped with only 2 DP lanes, which clips your dotclock to 144MHz at
8bpc. Of the standard DMT
On Wed, 2011-10-19 at 10:28 -0400, Adam Jackson wrote:
I assume the SDVO LVDS options block in the VBT would tell us what bits
are correct to program here, but intel_bios.h documents only the layout
of that structure, not its content. Or, we can hope that the SDVO card
set it up correctly
1 - 100 of 243 matches
Mail list logo
