[PATCH 4/4] drm/i915: add new param to force audio on or off for HDMI/DP port

Two reasons to add this param, one is for some AV device requiring HDMI input for audio, but some device might not have sane EDID info to enable audio on HDMI port. Another is for testing purpose. Signed-off-by: Zhenyu Wang --- drivers/gpu/drm/i915/i915_drv.c |3 +++ drivers/gpu/drm/i915/i

[PATCH 3/4] drm/i915: Enable HDMI audio for monitor with audio support

Rely on monitor's audio capability to turn on audio output for HDMI. Tested-by: Wu Fengguang Signed-off-by: Zhenyu Wang --- drivers/gpu/drm/i915/intel_hdmi.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/

[PATCH 2/4] drm/i915: Enable DisplayPort audio

This will turn on DP audio output by checking monitor's audio capability. Tested-by: Wu Fengguang Signed-off-by: Zhenyu Wang --- drivers/gpu/drm/i915/intel_dp.c | 61 +++ 1 files changed, 36 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/i915/

[PATCH 1/4] drm/edid: add helper function to detect monitor audio capability

To help to determine if digital display port needs to enable audio output or not. This one adds a helper to get monitor's audio capability via EDID CEA extension block. Tested-by: Wu Fengguang Signed-off-by: Zhenyu Wang --- drivers/gpu/drm/drm_edid.c | 92 +

[PATCH 0/4] updated patches for KMS audio

I found my check for audio capability within CEA extension might has some conflict with Adam's patch to add more detailed mode from CEA ext block. But I haven't found Adam's patch in next tree, so I just kept my current change. This fixed incorrect probe for DP monitor's audio. Fengguang helped to

Re: [PATCH 2/3] drm/i915: Enable DisplayPort audio

On 2010.09.16 14:31:31 +0800, Zhenyu Wang wrote: > This will turn on DP audio output by checking monitor's audio > capability. > oops, please ignore this one. Check EDID data after it's already freed... > Signed-off-by: Zhenyu Wang > --- > drivers/gpu/drm/i915/intel_dp.c |4 > 1 files

[Bug 29726] New CRTC ID query breaks Radeon DRM in Zaphod mode

https://bugs.freedesktop.org/show_bug.cgi?id=29726 --- Comment #3 from James Le Cuirot 2010-09-18 16:21:02 PDT --- I have now tested with two monitors, once in "clone" mode and once in "big desktop" mode and the behaviour is the same as with a single monitor. Just the occasional flicker. This is

[Bug 29726] New CRTC ID query breaks Radeon DRM in Zaphod mode

https://bugs.freedesktop.org/show_bug.cgi?id=29726 --- Comment #3 from James Le Cuirot 2010-09-18 16:21:02 PDT --- I have now tested with two monitors, once in "clone" mode and once in "big desktop" mode and the behaviour is the same as with a single monitor. Just the occasional flicker. This is

[PATCH] drm/edid: Don't repeatedly log hex dumps of bad EDIDs by default

On Fri, Sep 17, 2010 at 06:53:26PM -0400, Andy Walls wrote: > On my system, every 10 seconds drm_edid_block_valid() gets called 4 > times by radeon_dvi_detect(). This results in 4 instances of a > multi-line hex dump of the same EDID (non-)data being logged every 10 > seconds. > > Silence the hex

nouveau/ttm: BUG in ttm_bo_release_list

On Sat, Sep 18, 2010 at 09:39:21AM +1000, Ben Skeggs wrote: > On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote: > > Hi > > Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug > > a couple of times a day: > > > > [ 2869.618504] [ cut here ] >

nouveau/ttm: BUG in ttm_bo_release_list

On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote: > Hi > Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug a > couple of times a day: > > [ 2869.618504] [ cut here ] > [ 2869.618532] kernel BUG at drivers/gpu/drm/ttm/ttm_bo.c:153! > [ 2869.

[PATCH] drm/edid: Don't repeatedly log hex dumps of bad EDIDs by default

On Sat, 2010-09-18 at 13:50 +0200, Marcin Slusarz wrote: > On Fri, Sep 17, 2010 at 06:53:26PM -0400, Andy Walls wrote: > > On my system, every 10 seconds drm_edid_block_valid() gets called 4 > > times by radeon_dvi_detect(). This results in 4 instances of a > > multi-line hex dump of the same EDID

Re: [PATCH] drm/edid: Don't repeatedly log hex dumps of bad EDIDs by default

On Fri, Sep 17, 2010 at 06:53:26PM -0400, Andy Walls wrote: > On my system, every 10 seconds drm_edid_block_valid() gets called 4 > times by radeon_dvi_detect(). This results in 4 instances of a > multi-line hex dump of the same EDID (non-)data being logged every 10 > seconds. > > Silence the hex

Re: nouveau/ttm: BUG in ttm_bo_release_list

On Sat, Sep 18, 2010 at 09:39:21AM +1000, Ben Skeggs wrote: > On Fri, 2010-09-17 at 19:43 +0200, Marcin Slusarz wrote: > > Hi > > Since upgrade from 2.6.35 to 2.6.36-rc3 (nouveau tree) I'm hitting this bug > > a couple of times a day: > > > > [ 2869.618504] [ cut here ] >

[Bug 30227] Radom X.org freeze by a GPU lockup

https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #8 from DaNiMoTh 2010-09-18 04:12:56 PDT --- Uhm, black screen was here also with agpmode=-1, but I have no error message in logs. I was playing (for the first time) with GLX version of cairo-dock. So now for me both modes doesn't do

[Bug 30227] Radom X.org freeze by a GPU lockup

https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #8 from DaNiMoTh 2010-09-18 04:12:56 PDT --- Uhm, black screen was here also with agpmode=-1, but I have no error message in logs. I was playing (for the first time) with GLX version of cairo-dock. So now for me both modes doesn't do

[Bug 30227] Radom X.org freeze by a GPU lockup

https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #7 from DaNiMoTh 2010-09-18 04:01:46 PDT --- (In reply to comment #6) > Created an attachment (id=38780) --> (https://bugs.freedesktop.org/attachment.cgi?id=38780) > error with agpmode=1 > > When system load radeon modules with agpm

[Bug 30227] Radom X.org freeze by a GPU lockup

https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #7 from DaNiMoTh 2010-09-18 04:01:46 PDT --- (In reply to comment #6) > Created an attachment (id=38780) --> (https://bugs.freedesktop.org/attachment.cgi?id=38780) > error with agpmode=1 > > When system load radeon modules with agpm

[Bug 30227] Radom X.org freeze by a GPU lockup

https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #6 from DaNiMoTh 2010-09-18 03:59:13 PDT --- Created an attachment (id=38780) --> (https://bugs.freedesktop.org/attachment.cgi?id=38780) error with agpmode=1 When system load radeon modules with agpmode=1, I had this error (fortunat

[Bug 30227] Radom X.org freeze by a GPU lockup

https://bugs.freedesktop.org/show_bug.cgi?id=30227 --- Comment #6 from DaNiMoTh 2010-09-18 03:59:13 PDT --- Created an attachment (id=38780) --> (https://bugs.freedesktop.org/attachment.cgi?id=38780) error with agpmode=1 When system load radeon modules with agpmode=1, I had this error (fortunat

[PATCH] drm/edid: Don't repeatedly log hex dumps of bad EDIDs by default

On my system, every 10 seconds drm_edid_block_valid() gets called 4 times by radeon_dvi_detect(). This results in 4 instances of a multi-line hex dump of the same EDID (non-)data being logged every 10 seconds. Silence the hex dump from drm_edid_block_valid() unless a drm_debug module parameter fl

r300 PenumbraOverture complete hang 2.6.35/36-rc4 (regression)

Hello, Last week I reported a complete hang with PenumbraOverture on kernel 2.6.35 and 2.6.36-rc3. This week I tried 2.6.36-rc4, and I still get a complete hang after playing PenumbraOverture for about a minute. I'm not using any xorg.conf, I'm using KMS. I also tried without KMS, and then I

Re: Remaining BKL users, what to do

On Thursday 16 September 2010 20:32:36 Jens Axboe wrote: > On 2010-09-16 16:49, Steven Rostedt wrote: > > Git blame shows this to be your code (copied from block/blktrace.c from > > years past). > > > > Is the lock_kernel() needed here? (although Arnd did add it in 62c2a7d9) > > It isn't, it can