On Thu, Sep 29, 2011 at 06:09:32PM -0700, Keith Packard wrote:
> 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
Talking to the eDP DDC channel requires that the panel be powered
up. Wrap both the EDID and modes fetch code with calls to turn the vdd
power on and back off.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 31 ---
1 files changed, 28 insertions(
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit and then remember when that fires to ensure that the
appropriate delay is respecte
Store the panel power sequencing delays in the dp private structure,
rather than the global device structure. Who knows, maybe we'll get
more than one eDP device in the future.
Look at both the current hardware register settings and the VBT
specified panel power sequencing timings. Use the maximum
This eliminates a fairly long delay when power sequencing newer
hardware
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 51 +++
1 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu
The DP i2c initialization code does a couple of i2c transactions,
which means that an eDP panel must be powered up.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b
The return value was unused, so just stop doing that.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 02b5162..56146a2 100644
---
Any call to intel_dp_sink_dpms must ensure that the panel has power so
that the DP_SET_POWER operation will be correctly received. The only
one missing this was in intel_dp_prepare.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |2 ++
1 files changed, 2 insertions(+), 0 de
On eDP, DDC requires panel power, but turning that on uses the panel
power sequencing timing values fetch from the DPCD data.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp
The VDD force bit is turned on before touching the panel, but if it
was enabled, there was no call to turn it back off. Add a call.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
This ensures that the panel power sequencing is complete before
attempting to communicate over the aux channel.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/
Cleans up code dealing with eDP VDD a bit. Remove redundant checks in
callers
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/int
If the panel is powered up, there's no need to delay for the 'off'
interval when turning the panel on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/d
Using the same basic plan as the VDD force delayed power off, make
turning the panel power off asynchronous.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 71 +--
1 files changed, 53 insertions(+), 18 deletions(-)
diff --git a/drivers/g
We need to check eDP VDD force and panel on in several places, so
create some simple helper functions to avoid duplicating code.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 39 ++-
1 files changed, 26 insertions(+), 13 deletions(-)
di
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16 insertions(+), 20 delet
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1 deletions(-)
diff
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 22 +
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
---
drivers/gpu/drm/i915/i915_irq.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gp
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard
---
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
index 44fef5e..f0c
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/i915_reg.h |5 -
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/
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
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files changed, 10 insertion
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 th
On Tue, 2011-09-27 at 16:12 +1000, Bojan Smojver wrote:
> Does anyone have any idea what's causing this? Or better, how to fix
> it? I can confirm that as of kernel 3.1.0-rc7 this is still a problem.
Anyone?
--
Bojan
___
Intel-gfx mailing list
Intel-g
Hi,
> We think we've fixed all the related bugs in the kernel, so you can try
> flipping the switch and see what happens.
Manuelle re-enabling relaxedfencing brings speed back to normal, quite
a few pages that scrolled slow in firefox are now as snappy as before
2.15 :)
> However, I think your s
On Thu, 29 Sep 2011 16:42:39 +0200, Clemens Eisserer
wrote:
> I was able to bisect the performance regression, the commit which
> introduced it was:
>
> commit 686018f283f1d131073ef5917213e6a8ac013f26
> Author: Chris Wilson
> Date: Tue Apr 12 08:23:04 2011 +0100
>
> Turn relaxed-fencing
On Thu, Sep 29, 2011 at 04:42:39PM +0200, Clemens Eisserer wrote:
> I was able to bisect the performance regression, the commit which
> introduced it was:
>
> commit 686018f283f1d131073ef5917213e6a8ac013f26
> Author: Chris Wilson
> Date: Tue Apr 12 08:23:04 2011 +0100
>
> Turn relaxed-fenc
I was able to bisect the performance regression, the commit which
introduced it was:
commit 686018f283f1d131073ef5917213e6a8ac013f26
Author: Chris Wilson
Date: Tue Apr 12 08:23:04 2011 +0100
Turn relaxed-fencing off by default for older (pre-G33) chipset
Are there plans to re-enable relax
Hi,
For quite some time now I experience slow scrolling on some pages when
using FireFox,
now I took the time to find the culprit.
The slow scrolling only manifests when maximizing FireFox' window
(screen size is 1920x1280),
and manifests in "after-scrolling" (scrolling although mouse already stop
29 matches
Mail list logo
