On Fri, 18 Nov 2011 14:12:03 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
No this one should be looking at the bottom bit, so I think it's ok.
Sorry, bad mail edit. There's one 15 in both force_wake_mt_put and
force_wake_mt_get and they both need to be 16:
+void
On Fri, 18 Nov 2011 14:48:39 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
So the ECOBUS reg *is* in the GT power well. Which means in order to
read it we have to disable RC6 altogether, forcibly, using the 0xa090
reg, set up force wake, then re-enable RC6.
Not surprising the ECOBUS
RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. Make the default value for the parameter turn
it on in these cases. Setting the value to either 0 or 1 will force
the specified behavior.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm
):
drm/i915: enable cacheable objects on Ivybridge
Keith Packard (12):
agp: iommu_gfx_mapped only available if CONFIG_INTEL_IOMMU is set
drm/i915: Use mode_config.mutex in ironlake_panel_vdd_work
drm/i915: Module parameters using '-1' as default must be signed type
drm/i915
On Wed, 16 Nov 2011 18:14:55 +0100, Takashi Iwai ti...@suse.de wrote:
While refactoring of backlight control code in commit [a95735569:
drm/i915: Refactor panel backlight controls], the handling of the bit
0 of duty-cycle was gone except for pineview. This resulted in invalid
register values
On Wed, 28 Sep 2011 11:57:24 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
+ char __user *end = uaddr + size - 1;
...
+ if (ret == 0) {
+ if (((unsigned long)uaddr PAGE_MASK) !=
+ ((unsigned long)end PAGE_MASK))
+
On Wed, 16 Nov 2011 10:58:03 +0100, Takashi Iwai ti...@suse.de wrote:
When the brightness property is inquired while the backlight is disabled,
the driver returns a wrong value (zero) because it probes the value after
the backlight was turned off. This caused a black screen even after the
On Thu, 17 Nov 2011 17:45:40 -0500, Adam Jackson a...@redhat.com wrote:
Your silicon people worry me.
In any case, the changes are mostly to move bits around so that there
are two bits for pipe select
I don't even. Unless you're looking at some other version of the DP
spec than me, I was
On Wed, 16 Nov 2011 16:49:40 +0100, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
So we need to check whether DMAR is enabled (on the
entire system, i.e. the variable exported for the ilk workaround is
not good enough)
Can you figure out what *would* be sufficient? Getting semaphores turned
on
On Wed, 16 Nov 2011 21:18:13 +0100, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Last time I've played around with all the combinations, only
intel_iommu=off was good enough to prevent the hang.
intel_iommu=igd_off still hangs (which is what the current value
exported by the dmar code dopends
On Wed, 16 Nov 2011 21:56:37 +0100 (CET), Nicolas Kalkhof nkalk...@web.de
wrote:
Not quite. On my i7 2620M (Lenovo T420) the gpu frequently hangs when
decoding videos (vaapi) and running OpenGL apps/games at the same
time. Disabling iommu makes my system relatively stable even with rc6
-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_reg.h | 18 +
drivers/gpu/drm/i915/intel_dp.c | 151 ++-
2 files changed, 135 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index
On Wed, 09 Nov 2011 15:29:13 +0100, Michel Alexandre Salim
sali...@fedoraproject.org wrote:
the quirk table unreachable if i915_panel_use_ssc is set. This patch
reorders the tests so that the quirk table is checked first, the
i915_panel_use_ssc next and the original per-device setting last.
here -- we're supposed to make it so that the
command line can override the quirks, but there's no way to use a quirk
given the mis-declared parameter.
This is untested...
From e64ecadef40e3c2035cd4e9b967ffd83489bdea0 Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Wed, 9 Nov
On Fri, 4 Nov 2011 23:28:07 +0100, Cedric Sodhi man...@gmx.net wrote:
Non-text part: multipart/mixed
Hello,
between 3.1 and cc03bbf1 on linux-next there has been a regression which
causes the screen to go black (not blank, backlight is still lit) on
KMS. The system runs fine in the
On Sun, 23 Oct 2011 12:13:43 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Hi Keith,
This patch isn't in your -next pull request. Please consider merging for
3.2.
I've merged this to -next.
--
keith.pack...@intel.com
pgpWigHouv8wm.pgp
Description: PGP signature
On Sun, 23 Oct 2011 13:35:45 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Sun, 23 Oct 2011 14:09:07 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Keith, can take a look at patches 1-2 and consider merging them for 3.2?
Those two are
Reviewed-by: Chris Wilson
On Mon, 24 Oct 2011 00:11:57 +0200, Daniel Vetter dan...@ffwll.ch wrote:
This patch only fixes things up so that we prefault the entire page range
and not just the first PAGE_SIZE bytes (i.e. at most 2 pages). So I don't
see the risk of extending the current behaviour to all pages. Userspace
On Thu, 3 Nov 2011 12:57:08 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Modulo what we already discussed on irc about the PP_READY bit, and the
Right, the PP_READY bit requires that everything needed for PCH eDP be
running, even when you're using a CPU connected eDP panel, and so it's
On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
A few comments on this one (also, is it strictly required to fix your
bug)?
I think so; the panel definitely was not happy when I turned the link
off while the panel power was on. Having the mode setting and DPMS
On Thu, 3 Nov 2011 13:03:29 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Sneaky putting this bug fix into this patch. :)
Ickle already saw that, and I've split it out into a separate patch. I
don't think this is necessary, but it seems like a sensible change.
Don't you love the
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Thanks for your careful patch review here.
--
keith.pack...@intel.com
pgpgfyj2k2GbD.pgp
Description: PGP signature
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
I've updated the pch-edp-fixes branch with your suggestions and attached
your R-b: to the reviewed patches.
That leaves only the panel power sequencing changes,
On Thu, 3 Nov 2011 15:41:25 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Except for VDD?? That does come on... and shouldn't be any different
than a full power sequence as far as link training etc go...
Oh, that's a good point. Doing things in this order essentially forces
yet another
Here's a patch sequence which makes my PCH-connected eDP panel
work. The main bug was a pile of places where the driver was
incorrectly treating a PCH connected eDP panel like a CPU connected
eDP panel, setting incorrect bits in the DP_CTL register and failing
to configure the TRANS_DP_CTL
Every usage of PCH_PP_CONTROL sets the PANEL_UNLOCK_REGS value to
ensure that writes will be respected, move this to a common function
to make the driver cleaner.
No functional changes.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 37
Make sure the sequence of operations in all three functions makes
sense:
1) The backlight must be off unless the screen is running
2) The link must be running to turn the eDP panel on/off
3) The CPU eDP PLL must be running until everything is off
Signed-off-by: Keith Packard kei...@keithp.com
The panel power sequencing hardware tracks the stages of panel power
sequencing and signals when the panel is completely on or off. Instead
of blindly assuming the panel timings will work, poll the panel power
status register until it shows the correct values.
Signed-off-by: Keith Packard kei
PCH eDP has many of the same needs as regular PCH DP connections,
including the DP_CTl bit settings, the TRANS_DP_CTL register.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c |3 +-
drivers/gpu/drm/i915/intel_dp.c | 112
Found a couple of bare tabs in intel_dp.c
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf20a35..7ebeb01 100644
No persistent data was ever stored here, so link_status is instead
allocated on the stack as needed.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 65 +-
1 files changed, 36 insertions(+), 29 deletions(-)
diff --git
Instead of going through the sequence just once, run through the whole
set up to 5 times to see if something can work. This isn't part of the
DP spec, but the BIOS seems to do it, and given that link training
failure is so bad, it seems reasonable to follow suit.
Signed-off-by: Keith Packard kei
On Tue, 1 Nov 2011 23:20:27 -0700, Keith Packard kei...@keithp.com wrote:
-static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
+#define IDLE_ON_MASK (PP_ON | PP_READY | PP_SEQUENCE_MASK | 0
| PP_SEQUENCE_STATE_MASK)
+#define IDLE_ON_VALUE(PP_ON
On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson a...@redhat.com wrote:
Redundant. You've already done the link_configuration |= above in the
common code. You can drop the second if chunk altogether.
Thanks for catching this mistake; cutpaste programming without the cut part...
In related
On Wed, 2 Nov 2011 09:20:19 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
But I was curious about this hunk:
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
drm_display_mode *mode,
continue;
intel_dp =
On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Note that PP_READY will incorrectly depend on some other register
values, so in some configs the panel will happily power up even if
PP_READY isn't set yet...
Yeah, I'd like to understand why PP_READY isn't
On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson a...@redhat.com wrote:
Given the choice of trusting DPCD or the VBT, I'd definitely prefer
DPCD.
Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the platform which may neglect to connect some
of
On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson a...@redhat.com wrote:
Redundant. You've already done the link_configuration |= above in the
common code. You can drop the second if chunk altogether.
Here's the new version of that chunk of patch:
@@ -850,32 +864,45 @@
On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Note that PP_READY will incorrectly depend on some other register
values, so in some configs the panel will happily power up even if
PP_READY isn't set yet...
Here's the new version of that chunk:
@@ -906,32
On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
This would seem to be a separate chunk to initiate training on only the
lanes we intend to use.
-Chris
Here's that patch separated out:
commit e7fecae483754ca9a42312be18f58ceb454702fe
Author: Keith Packard kei
value everywhere.
Signed-off-by: Keith Packard kei...@keithp.com
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 02b56ce..5056d29 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -154,16 +154,12
On Sun, 30 Oct 2011 18:20:54 -0700, Ben Widawsky b...@bwidawsk.net wrote:
The solution here is to add a new flag to the call chain which gives the
routines the information they need to possibly defer actions which may
cause us to recurse.
This looks a lot nicer; it's shorter than I feared
On Sun, 30 Oct 2011 18:52:10 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Well, I had to pick one, and looking at the call chain, it seemed there wasn't
much to gain by doing retiring at this point.
The point is that you're mixing the stuff the commit message talks about
with other changes
Steve Langasek came over today and we hacked on the i915 driver
initialization code to try and avoid the initial mode set. I thought I'd
summarize what we found out.
* Ubuntu has hacked up grub2 so that it gets the boot monitor running
in a reasonable configuration using VBE calls if
On Sat, 29 Oct 2011 09:12:13 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Sat, 29 Oct 2011 00:05:22 -0700, Keith Packard kei...@keithp.com wrote:
* Constructing a fake drm_framebuffer is a pain; there are a million
places that assume all kinds of things about the frame buffer
On Sat, 29 Oct 2011 19:07:23 -0700, Ben Widawsky b...@bwidawsk.net wrote:
+ /**
+ * Flag if GTT ptes shouldn't be modified.
+ *
+ * This is set when graphics virtual address space
+ * should not be changed. It's currently only
On Sat, 29 Oct 2011 19:56:43 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Sigh. I started down that path, but it was becoming tedious with only
one case where we actually want to not retire (I think), so I thought
I'd see how this went down on the mailing list.
I don't even want to think
On Sat, 29 Oct 2011 00:05:22 -0700, Keith Packard kei...@keithp.com wrote:
* I've got LVDS pulling the current mode out of the hardware
With a machine that has a native VBE mode for the panel, the problem is
that clock computed from the hardware settings is not quite the same as
the clock
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard kei...@keithp.com
Cc: Ben Widawsky b...@bwidawsk.net
---
drivers/char/agp
Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.
Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: Keith Packard kei...@keithp.com
Cc: Ben Widawsky b...@bwidawsk.net
---
Here's a shorter
On Tue, 25 Oct 2011 12:25:45 -0400, Adam Jackson a...@redhat.com wrote:
I can respin patch 2 if there's still interest, but it might be
difficult to find a monitor to test against. Patch 1 is still valid
though.
I've applied patch 1. I don't have a monitor to test patch 2 against, so
if
On Mon, 24 Oct 2011 08:14:45 +, Woodhouse, David
david.woodho...@intel.com wrote:
The IOMMU patches are now in Linus' tree and thus will be in the 3.1
release. Are we going to push the graphics patches in time for the 3.1
release too?
The graphics patches are in the 3.2 pull request;
drm/i915: read full receiver capability field during DP hot plug
drm/i915: add DP test request handling
drm/i915: fix ILK+ infoframe support
drm/i915: use correct SPD type value
Keith Packard (30):
drm/i915: broken copyright encoding in intel_bios.c
drm/i915: Use
On Sun, 23 Oct 2011 12:03:32 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Hi Keith,
This patch hasn't shown up in your -next pull request. Please consider
merging for 3.2.
So small I missed it? I'll send it in the next set after Dave merges
what I've posted so far.
--
On Sun, 23 Oct 2011 12:13:43 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Hi Keith,
This patch isn't in your -next pull request. Please consider merging for
3.2.
I didn't ever see a reply from Nicolas that it fixed his problem; would
be nice to know whether this actually worked...
--
On Sun, 23 Oct 2011 12:18:30 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Hi Keith,
This patch isn't in your -next pull. This papers over a spurious -EFAULT
in the pwrite/pread paths that actually gets hit in the wild. The real fix
in the form of a almost complete rewrite of the pwrite/pread
On Wed, 19 Oct 2011 08:12:08 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
/* PCH eDP needs FDI, but CPU eDP does not */
- if (!has_edp_encoder ||
intel_encoder_is_pch_edp(has_edp_encoder-base)) {
+ if (!intel_crtc-no_pll
+ (!has_edp_encoder ||
+
On Fri, 21 Oct 2011 12:00:26 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yeah works much better with this applied. Makes me want to change the
PLL sharing code a bit though; this should be factored out into a
separate function and I should probably just add a tiny PLL allocator
for
On Thu, 16 Jun 2011 21:58:42 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Rolf,
This looks to be the missing ingredient for your board. Can you please
give it a test?
I haven't seen a tested-by, reviewed-by or even acked-by for this patch
yet.
--
keith.pack...@intel.com
On Sat, 17 Sep 2011 20:55:44 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
io-mapping: ensure io_mapping_map_atomic _is_ atomic
drm/i915: drop KM_USER0 argument to k(un)map_atomic
These have been merged.
drm/i915: fall through pwrite_gtt_slow to the shmem slow path
drm/i915:
On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov eug...@dodonov.net wrote:
From what I've checked, the other return error value in this context could
be -EREMOTEIO, which could be caused by transmission error so it should be
retried.
Oh, there's -ENOMEM, -EINVAL and probably a few others
tested a marginal case and had it
work :-)
Acked-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpN3hFtBxndn.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org
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; the comment before that function
should have indicated to any
On Fri, 14 Oct 2011 12:43:50 -0400, Adam Jackson a...@redhat.com wrote:
These were just working around the math being wrong.
One wonders whether this might break some machines which are currently
working. Should we emit an error or something if an eDP panel asks for
the impossible?
--
On Wed, 12 Oct 2011 15:41:11 +0100, Dave Airlie airl...@gmail.com wrote:
Using the same basic plan as the VDD force delayed power off, make
turning the panel power off asynchronous.
NAK, tested on my 2540p, up to this patch in macbook-air branch stuff
worked, after this I just get black
On Wed, 12 Oct 2011 11:12:59 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
+#define CURCNTR_IVB(pipe) _PIPE(pipe, _CURACNTR, _CURBCNTR_IVB)
+#define CURBASE_IVB(pipe) _PIPE(pipe, _CURABASE, _CURBBASE_IVB)
+#define CURPOS_IVB(pipe) _PIPE(pipe, _CURAPOS, _CURBPOS_IVB)
Only two cursors?
On Tue, 11 Oct 2011 09:40:18 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Ok just got confirmation that always setting the composite bit is safe
on IVB per the specs we provide to board designers (i.e. they're
required to make composite sync work, and fsync/lsync is optional).
Thanks.
On Tue, 11 Oct 2011 11:53:56 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Keith can you pick this up?
Yup, I'll make it work.
--
keith.pack...@intel.com
pgpEirXYXMjwW.pgp
Description: PGP signature
___
Intel-gfx mailing list
On Thu, 6 Oct 2011 07:31:44 +0100, Dave Airlie airl...@gmail.com wrote:
You can't say no there, you need to make a decision from the
information provided.
Yeah, you'd end up having to use two modes with the same clock. Let's
hope DisplayPort ends up a lot more popular than it has gotten so
On Wed, 5 Oct 2011 11:26:26 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Was just preserving the old code; I think you've fixed this issue
already in another patch (looks like it's another one that's been there
since we first brought up ILK?).
I think the only case where we select the
On Wed, 5 Oct 2011 12:56:47 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Unfortunately, (2) complicates our mode list output. If you query for
available modes, you'll definitely see some that you can't drive with 3
pipes enabled. I'm not sure if the best way to handle that...
All we
On Tue, 4 Oct 2011 17:53:08 +0800, meteor met...@ms1.url.com.tw wrote:
Please refer to the VDD power monitoring image:
http://imageshack.us/photo/my-images/827/auoi.jpg/
Nice picture. As Daniel mentioned, you'll want to try my eDP power
sequencing changes and see what they do.
I'm not sure
On Mon, 3 Oct 2011 13:00:16 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
This is the only bit I'd like to see changed. While we still have the
domain tracking code we may as well try to honor it and limit our
flushing here like we do with MI_FLUSH.
I'd like to see this patch put in
On Tue, 20 Sep 2011 15:29:47 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Add the addresses and definitions I care about for Panel Self Refresh, as
documented in the eDP spec.
I generally review the addresses and bit definitions for any new
registers -- getting them wrong makes debugging the
On Mon, 3 Oct 2011 14:14:23 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Now... is keeping the various refclks enabled costing us any power?
IOW, should we be trying to disable them when everything has been
DPMS'd off too?
That's the same as tracking usage and enabling/disabling on
On Mon, 3 Oct 2011 15:14:14 -0700, Ben Widawsky b...@bwidawsk.net wrote:
+# define DP_PSR_SUPPORTED 1
That's PSR version 1, not just a simple boolean
+# define DP_PSR_SETUP_TIME_330 (0 1)
+# define DP_PSR_SETUP_TIME_275 (1 1)
+# define
On Mon, 3 Oct 2011 16:21:08 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Agreed; fortunately shutting everything off when no outputs are
active should be simpler than trying flip the bits on off every mode
set. :)
We'd have to track when outputs are shut off; just tracking per clock
On Sun, 2 Oct 2011 18:27:12 -0700, Ben Widawsky b...@bwidawsk.net wrote:
+static void blt_ring_begin2(struct intel_ring_buffer *ring)
+{
+ if (!ring-private)
+ return;
+
+ intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+ intel_ring_emit(ring, 0x2209c);
+
On Sat, 1 Oct 2011 11:59:09 +0200, Daniel Vetter dan...@ffwll.ch wrote:
So while you bang your head against this, can you add the backlight power
sequencing delays for lvds panels, too? The lvds panel power sequencing
should be imo safe - we just msleep-spin with wait_for until the power
On Sat, 1 Oct 2011 12:55:40 -0400, Alec Moskvin al...@gmx.com wrote:
I updated my kernel from 3.0.4 to 3.1-rc8 and now anytime the display
turns off (xscreensaver, close the lid, xset dpms force off), when it
comes back up, it shows what was shown before, but the image does not
update -
On Thu, 29 Sep 2011 20:33:56 -0700, Greg KH g...@kroah.com wrote:
Are these really all -stable material?
I think just the sequence that actually makes the machine work; the
scarier patches are those which reduce the mode setting time from 5-10s
down to .7s.
Is this stretching the bounds of
On Fri, 30 Sep 2011 18:20:48 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Shouldn't we mask/ack south DE irqs before before we mask DE irqs to avoid
races, i.e. move this new code up?
I don't know. What about the GT interrupts? I just stuck stuff at the
bottom, figuring it would do the least
On Fri, 30 Sep 2011 18:27:28 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Can you elaborate a bit why this is no longer needed? Jesse seems to have
introduced this spefically for edp panels in d209848d61794968. If this
becomes rendundant due to your panel power sequencing fixes, maybe move it
On Fri, 30 Sep 2011 18:32:35 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Ok, this is way over my head, just checked whether the patch does what it
claims to - nice exercise in reading dp modeset code ;-)
Yeah, it's purely heuristic -- the VBT contains a mode which was
originally for the LVDS.
On Fri, 30 Sep 2011 19:02:42 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Use pp_control instead of re-reading?
Could, but you'll note a later patch eliminates both pp_status and
pp_control local variables, so I didn't bother to clean this up when
refactoring.
dp_aux_ch does the low-level io
On Fri, 30 Sep 2011 19:13:55 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Why not also move the id_edp check into edp_panel_on|off like for the vdd
functions? This way it looks a bit inconsistent ...
Yeah, I can do that. May mean a few redundant checks, but they're cheap.
--
On Fri, 30 Sep 2011 11:31:45 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I think you want the dev-mode_config.mutex here.
oops. good catch.
--
keith.pack...@intel.com
pgpRqas0gw16q.pgp
Description: PGP signature
___
Intel-gfx mailing list
On Fri, 30 Sep 2011 09:20:55 -0400, Ted Ts'o ty...@mit.edu wrote:
What kind of battery life do you get with these patches applied, out
of curiosity?
4-5 hours when doing the usual web-surfing, etc. Seems pretty much the
same as people are getting under Mac OS.
--
keith.pack...@intel.com
On Fri, 30 Sep 2011 20:09:59 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On further strolling through bspec to review later patches I've noticed
that PCH_PP_ON_DELAYS and PCH_PP_OFF_DELAYS seem to have values for
power on-backlight on and backlight off-panel off delays. Maybe we
should use
On Fri, 30 Sep 2011 19:45:02 +0200, Daniel Vetter dan...@ffwll.ch wrote:
If I understand things correctly we don't need the vdd_on/off on dpms off
because the panel is running and has power.
Yes, that's correct; the aux channel works with either full power or
with the force VDD bit turned on.
On Fri, 30 Sep 2011 20:01:11 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Looks like a patch useful for fixing up this mess, but I don't quite see
the point of merging this given that you fix things for real in the next
one ...
Good point. In the development process, this was the patch which
On Fri, 30 Sep 2011 20:47:00 +0200, Daniel Vetter dan...@ffwll.ch wrote:
A cancel_work might be good here, not point in waking up the cpu for no
reason. And can you add panel off timer: to the deboug output?
No, that's not correct, this is run before turning the panel back on and
must check
On Fri, 30 Sep 2011 20:55:24 +0200, Daniel Vetter dan...@ffwll.ch wrote:
If it's not too annoying to do, can you move this to the previous patch?
Dito for the s/panel_vdd_work/panel_work/.
Yeah, that was a bit of sloppy patch mangling.
Same comment as in the previous patch: I think the
On Fri, 30 Sep 2011 19:09:46 +0200, Daniel Vetter dan...@ffwll.ch wrote:
grep shows that we also write to PCH_PP_CONTROL in intel_lvds.c in the
dpms functions - any reasons these two writes are left out?
Upon a bit of review:
The bspec makes it clear that this write protect key only needs
On Fri, 30 Sep 2011 20:16:44 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Awesome patch description and the code agrees with what I've cross-checked
on bspec. The only fear I have is that we currently ignore the backlight
on/off timings and some panel probably relies on use waiting for
Ok, so I've split all of the changes into bite-sized pieces so that
they should make sense individually now. I've also added the same
asynchronous power control to the panel power, this reduces the
module load time down to about 700ms on my MacBook Air, which is
pretty nice.
Given the length of
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/i915_reg.h |5 -
2 files changed, 28 insertions(+), 1 deletions(-)
diff
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
This masks out all interrupts and ack's any pending ones at IRQ
uninstall time to make sure we don't receive any unexpected interrupts
later on.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_irq.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff
201 - 300 of 603 matches
Mail list logo
