[PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd

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 kei...@keithp.com --- drivers/gpu/drm/i915/intel_dp.c |8 +++- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git

[PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper function

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 first plugged back in and the link needs to be retrained.

[PATCH 2/5] drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd

This describes the function better, allowing it to be used where the DPCD value is relevant. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/intel_dp.c | 24 +++- 1 files changed, 15 insertions(+), 9 deletions(-) diff --git

[PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT

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. This patch replaces the simplistic macro DP_PIPE_ENABLED with

[PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code

If the connector is inserted or removed slowly, the hotplug line may well change state before the data lines do. So, assume the user isn't trying to fool us and give them 250ms to get the connector plugged or unplugged. Signed-off-by: Keith Packard kei...@keithp.com ---

drm/i915: A selection of display port fixes

[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 places where the DPCD block was read from the device. Now

Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

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

[git pull] drm pull for -rc1

Hi Linus, Main drm pull request for -rc1, main highlights, Nouveau: open source fermi ucode, per-client gpu address spaces for nv50 and up. Intel: FBC cleanups (on by default now), high color support, ring frequency scaling, shared LLC support, and hangcheck module disabling. radeon: initial

[Bug 35697] System locks up when watching fullscreen flash video

https://bugs.freedesktop.org/show_bug.cgi?id=35697 Nikos Chantziaras rea...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

On Tue, Jul 26, 2011 at 1:54 AM, Keith Packard kei...@keithp.com wrote: From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001 From: Keith Packard kei...@keithp.com Date: Mon, 25 Jul 2011 22:37:51 -0700 Subject: [PATCH] Revert and fix drm/i915/dp: remove DPMS mode tracking from

Re: [PATCH] drm/radeon: Fix ECS A740GM-M DVI-D EDID error flooding problem

On Wed, Jul 20, 2011 at 4:34 AM, rei...@googlemail.com wrote: From: Thomas Reim rei...@gmail.com   ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus   for a DVI connector that is not implemented/existent on the board.   Fix by applying extented DDC probing for this connector.  

Re: [Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

On Sat, Jul 23, 2011 at 11:10:53AM -0400, Alex Deucher wrote: On Fri, Jul 22, 2011 at 5:31 PM, Kirill Smelkov k...@mns.spb.ru wrote: On Sat, Jul 23, 2011 at 01:08:14AM +0400, Kirill Smelkov wrote: On Fri, Jul 22, 2011 at 01:50:04PM -0700, Keith Packard wrote: You're right, of course --

Re: [PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem

On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Jul 6, 2011 at 7:30 PM,  rei...@googlemail.com wrote: From: Thomas Reim rdrat...@yahoo.co.uk Guys I really still hate this :-) Other OSes must deal with this sort of thing and I can't say they don't do it like

Re: [PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem

On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie airl...@gmail.com wrote: On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Jul 6, 2011 at 7:30 PM,  rei...@googlemail.com wrote: From: Thomas Reim rdrat...@yahoo.co.uk Guys I really still hate this :-) Other OSes

Re: [PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem

On Tue, Jul 26, 2011 at 10:52 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie airl...@gmail.com wrote: On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Jul 6, 2011 at 7:30 PM,  rei...@googlemail.com wrote: From: Thomas

Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter dan...@ffwll.ch 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

Re: [PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code

On Tue, 26 Jul 2011 09:44:32 +0200, Daniel Vetter dan...@ffwll.ch wrote: queue_delayed_work? Plays nicer with other workqueue-items. Yeah, I'll change this. -- keith.pack...@intel.com pgpifulG3hqfz.pgp Description: PGP signature ___ dri-devel

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd

On Mon, 25 Jul 2011 23:36:31 -0700 Keith Packard kei...@keithp.com wrote: This describes the function better, allowing it to be used where the DPCD value is relevant. Signed-off-by: Keith Packard kei...@keithp.com --- Ah I see you've addressed my previous comment already. :) You can add

Re: [Intel-gfx] [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd

On Mon, 25 Jul 2011 23:36:32 -0700 Keith Packard kei...@keithp.com 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 kei...@keithp.com --- drivers/gpu/drm/i915/intel_dp.c |8 +++-

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper function

On Mon, 25 Jul 2011 23:36:30 -0700 Keith Packard kei...@keithp.com 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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT

On Mon, 25 Jul 2011 23:36:34 -0700 Keith Packard kei...@keithp.com 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

Re: [Intel-gfx] drm/i915: A selection of display port fixes

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

Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

On Tue, 26 Jul 2011 08:23:13 -0700 Keith Packard kei...@keithp.com wrote: On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter dan...@ffwll.ch 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

[Bug 39572] New: Cogs: GPU hang

https://bugs.freedesktop.org/show_bug.cgi?id=39572 Summary: Cogs: GPU hang Product: Mesa Version: git Platform: Other URL: http://www.humblebundle.com/ OS/Version: All Status: NEW Severity: normal

[PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt

From: Jerome Glisse jgli...@redhat.com Some CP interrupt were left enabled when disabling interrupt. Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/evergreen.c |2 +- drivers/gpu/drm/radeon/r600.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt

On Tue, Jul 26, 2011 at 5:28 PM, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Some CP interrupt were left enabled when disabling interrupt. Is there a specific issue this fixes? The bits are not interrupt sources per se but rather are related to the internal state of the

Re: [PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt

On Tue, Jul 26, 2011 at 5:47 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jul 26, 2011 at 5:28 PM,  j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Some CP interrupt were left enabled when disabling interrupt. Is there a specific issue this fixes?  The bits are not

[PATCH] drm/radeon/kms: fix version comment due to merge timing

From: Alex Deucher alexander.deuc...@amd.com Compute cs support was actually added in 2.11.0 rather than 2.10.0, but the patch was written prior. Update comment to match. Signed-off-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/radeon_drv.c |4 ++-- 1 files changed,

[PATCH 1/4] drm: add plane support

2011/7/25 Rob Clark : > On Mon, Jul 25, 2011 at 3:18 AM, Joonyoung Shim wrote: >> 2011/7/22 Jesse Barnes : >>> On Thu, 21 Jul 2011 19:30:00 +0900 >>> Joonyoung Shim wrote: >>> Hi, simple questions :) 2011/6/21 Jesse Barnes : > Planes are a bit like half-CRTCs. ?They

[PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd

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 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c

[PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper function

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 first plugged back in and the link needs to be retrained.

[PATCH 2/5] drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd

This describes the function better, allowing it to be used where the DPCD value is relevant. Signed-off-by: Keith Packard --- drivers/gpu/drm/i915/intel_dp.c | 24 +++- 1 files changed, 15 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c

[PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT

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. This patch replaces the simplistic macro DP_PIPE_ENABLED with

[PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code

If the connector is inserted or removed slowly, the hotplug line may well change state before the data lines do. So, assume the user isn't trying to fool us and give them 250ms to get the connector plugged or unplugged. Signed-off-by: Keith Packard --- drivers/gpu/drm/i915/i915_irq.c |2 ++

drm/i915: A selection of display port fixes

[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 places where the DPCD block was read from the device. Now

[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

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.

[PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code

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.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch

[git pull] drm pull for -rc1

Hi Linus, Main drm pull request for -rc1, main highlights, Nouveau: open source fermi ucode, per-client gpu address spaces for nv50 and up. Intel: FBC cleanups (on by default now), high color support, ring frequency scaling, shared LLC support, and hangcheck module disabling. radeon: initial

[Bug 35697] System locks up when watching fullscreen flash video

https://bugs.freedesktop.org/show_bug.cgi?id=35697 Nikos Chantziaras changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

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

[PATCH] drm/radeon: Fix ECS A740GM-M DVI-D EDID error flooding problem

On Wed, Jul 20, 2011 at 4:34 AM, wrote: > From: Thomas Reim > > ? ECS A740GM-M with ATI RADEON 2100 sends data to i2c bus > ? for a DVI connector that is not implemented/existent on the board. > > ? Fix by applying extented DDC probing for this connector. > > ? Requires [PATCH] drm/radeon: Fix

[PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem

On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote: > On Wed, Jul 6, 2011 at 7:30 PM, ? wrote: >> From: Thomas Reim Guys I really still hate this :-) Other OSes must deal with this sort of thing and I can't say they don't do it like this but I can't say for certain this feels like the right

[PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem

On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote: > On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher wrote: >> On Wed, Jul 6, 2011 at 7:30 PM, ? wrote: >>> From: Thomas Reim > > Guys I really still hate this :-) > > Other OSes must deal with this sort of thing and I can't say they > don't do it

[PATCH 2/3] drm/radeon: Fix Asus M2A-VM HDMI EDID error flooding problem

On Tue, Jul 26, 2011 at 10:52 AM, Alex Deucher wrote: > On Tue, Jul 26, 2011 at 9:20 AM, Dave Airlie wrote: >> On Thu, Jul 7, 2011 at 3:01 PM, Alex Deucher >> wrote: >>> On Wed, Jul 6, 2011 at 7:30 PM, ? wrote: From: Thomas Reim >> >> Guys I really still hate this :-) >> >> Other OSes

[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110726/1b607231/attachment-0001.pgp>

[PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code

pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110726/8c274b70/attachment.pgp>

[Intel-gfx] [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd

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

[Intel-gfx] [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd

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

[Intel-gfx] [PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper function

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

[Intel-gfx] [PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT

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

[Intel-gfx] drm/i915: A selection of display port fixes

-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110726/2993b7d6/attachment.pgp>

[Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

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

[Bug 39572] New: Cogs: GPU hang

https://bugs.freedesktop.org/show_bug.cgi?id=39572 Summary: Cogs: GPU hang Product: Mesa Version: git Platform: Other URL: http://www.humblebundle.com/ OS/Version: All Status: NEW Severity: normal

[PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt

From: Jerome Glisse Some CP interrupt were left enabled when disabling interrupt. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/evergreen.c |2 +- drivers/gpu/drm/radeon/r600.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt

On Tue, Jul 26, 2011 at 5:28 PM, wrote: > From: Jerome Glisse > > Some CP interrupt were left enabled when disabling interrupt. > Is there a specific issue this fixes? The bits are not interrupt sources per se but rather are related to the internal state of the interrupt controller and should

[PATCH] drm/radeon/kms: disable CP interrupt when disabling interrupt

On Tue, Jul 26, 2011 at 5:47 PM, Alex Deucher wrote: > On Tue, Jul 26, 2011 at 5:28 PM, ? wrote: >> From: Jerome Glisse >> >> Some CP interrupt were left enabled when disabling interrupt. >> > > Is there a specific issue this fixes? ?The bits are not interrupt > sources per se but rather are

[Intel-gfx] Major 2.6.38 / 2.6.39 / 3.0 regression ignored?

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

[PATCH] i915: add Dell OptiPlex FX170 to intel_no_lvds

The Dell OptiPlex FX170 claims to have LVDS, but doesn't. Signed-off-by: Pieterjan Camerlynck --- drivers/gpu/drm/i915/intel_lvds.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index