On Tue, 26 Jul 2011 16:53:06 -0400
Adam Jackson wrote:
> At least on a Lenovo X220 the HPD bits of this are enabled at boot but
> cleared after resume, which means plug interrupts stop working.
>
> This also happens to fix DP displays re-lighting on resume. I'm quite
> certain that's an acciden
At least on a Lenovo X220 the HPD bits of this are enabled at boot but
cleared after resume, which means plug interrupts stop working.
This also happens to fix DP displays re-lighting on resume. I'm quite
certain that's an accident: the first DP link train inevitably fails on
that machine, and it
This is paranoid, but I am entirely willing to believe the hardware
could come up with a condition where I get a status with both the 'done'
and 'receive error' bits set.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
Matches the advice in the Sandybridge documentation.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dcc7ae6..3ad90f6 100644
--- a/dri
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
---
drivers/gpu/drm/i915/intel_dp.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/driv
On Tue, 26 Jul 2011 08:23:13 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> > Two things I've noticed:
>
> > - Why not dev->mode_config.mutex?
>
> You're right, of course. I noticed that just after posting that version
> and updated it; the updated vers
On Mon, 2011-07-25 at 23:36 -0700, Keith Packard wrote:
> [PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper
> [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to
> [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with
>
> These three are simple cleanups to centralize all
On Mon, 25 Jul 2011 23:36:34 -0700
Keith Packard wrote:
> Display port pipe selection on CPT is not done with a bit in the
> output register, rather it is controlled by a couple of bits in the
> separate transcoder register which indicate which display port output
> is connected to the transcoder
On Mon, 25 Jul 2011 23:36:30 -0700
Keith Packard wrote:
> This uses the common dpcd reading routine, i915_dp_detect_common,
> instead of open-coding a call to intel_dp_aux_native_read. Besides
> reducing duplicated code, this also gains the read retries which
> may be necessary when a cable is fi
On Mon, 25 Jul 2011 23:36:32 -0700
Keith Packard wrote:
> Eliminates an open-coded read and also gains the retry behaviour of
> intel_dp_get_dpcd, which seems like a good idea.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_dp.c |8 +++-
> 1 files changed, 3 insert
On Mon, 25 Jul 2011 23:36:31 -0700
Keith Packard wrote:
> This describes the function better, allowing it to be used where the
> DPCD value is relevant.
>
> Signed-off-by: Keith Packard
> ---
Ah I see you've addressed my previous comment already. :)
You can add my
Reviewed-by: Jesse Barnes t
On Tue, 26 Jul 2011 09:44:32 +0200, Daniel Vetter wrote:
> queue_delayed_work? Plays nicer with other workqueue-items.
Yeah, I'll change this.
--
keith.pack...@intel.com
pgpmBnOF4ET1G.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-
On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> Two things I've noticed:
> - Why not dev->mode_config.mutex?
You're right, of course. I noticed that just after posting that version
and updated it; the updated version is on my drm-intel-fixes branch
already (having been reviewed by Jes
On Sat, Jul 23, 2011 at 12:23:36AM +0400, Kirill Smelkov wrote:
> Keith,
>
> first of all thanks for your prompt reply. Then...
>
> On Fri, Jul 22, 2011 at 11:00:41AM -0700, Keith Packard wrote:
> > On Fri, 22 Jul 2011 15:08:06 +0400, Kirill Smelkov wrote:
> >
> > > And now after v3.0 is out, I
On Tue, Jul 26, 2011 at 1:54 AM, Keith Packard wrote:
> From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001
> From: Keith Packard
> Date: Mon, 25 Jul 2011 22:37:51 -0700
> Subject: [PATCH] Revert and fix "drm/i915/dp: remove DPMS mode tracking from
> DP"
>
> This reverts commi
Dear graphics folks,
Am Montag, den 25.07.2011, 22:33 +0200 schrieb Paul Menzel:
> using `linux-image-3.0.0-1-686-pae` from Debian Sid/unstable I noticed
> the following message in `dmesg`.
>
> [ 76.292185] [drm] capturing error event; look for more information
> in /debug/dri/0/i915
queue_delayed_work? Plays nicer with other workqueue-items.
-Daniel
PS: Scrap my other mail, just noticed that the merged patched r-b'ed
by Jesse uses the mode_config mutex.
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
Two things I've noticed:
- Why not dev->mode_config.mutex? I was under the impression that
mode_config.mutex protects most of the modesetting state and
dev->struct_mutex protects things related to the gpu execution cores
(i.e. all things gem), with struct_mutex nested within
mode_config.mutex. It's
18 matches
Mail list logo
