r300 PenumbraOverture complete hang 2.6.35/36-rc4 (regression)
Il giorno ven, 17/09/2010 alle 21.46 +0200, PJBrs ha scritto: > 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 > have no problem. 2.6.34 is the last kernel that worked with KMS. > > I got no reaction on my first mail; could you please let me know whether > this report is useful at all? And if so, could you please let me know if > I should file this in Bugzilla? I searched bugzilla but I couldn't find > anything like I'm reporting here. Also, this problem does not seem to be > reported as a kernel regression. > > Or maybe the problem is that I'm not subscribed to the dri-devel mailing > list. > > My graphics adapter is an ATI Technologies Inc M24GL [Mobility FireGL > V3200] (rev 80), and I'm using Slackware 13.1 with Mesa 7.8.1, Xserver > 1.7.7. I wasn't able to get any further information--I tried running the > game with all graphics options turned off, but it didn't help. > > Anyway, I'd really like this problem to be solved, and I'd very much > like to help out as much as I can. > > PJ Hi, I missed this message when it was first sent. Could you check if this is bug 29389 (https://bugs.freedesktop.org/show_bug.cgi?id=29389)? The latest 2.6.36 RCs should already have the kernel parameter to disable polling. Giacomo
Re: r300 PenumbraOverture complete hang 2.6.35/36-rc4 (regression)
Il giorno ven, 17/09/2010 alle 21.46 +0200, PJBrs ha scritto: 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 have no problem. 2.6.34 is the last kernel that worked with KMS. I got no reaction on my first mail; could you please let me know whether this report is useful at all? And if so, could you please let me know if I should file this in Bugzilla? I searched bugzilla but I couldn't find anything like I'm reporting here. Also, this problem does not seem to be reported as a kernel regression. Or maybe the problem is that I'm not subscribed to the dri-devel mailing list. My graphics adapter is an ATI Technologies Inc M24GL [Mobility FireGL V3200] (rev 80), and I'm using Slackware 13.1 with Mesa 7.8.1, Xserver 1.7.7. I wasn't able to get any further information--I tried running the game with all graphics options turned off, but it didn't help. Anyway, I'd really like this problem to be solved, and I'd very much like to help out as much as I can. PJ Hi, I missed this message when it was first sent. Could you check if this is bug 29389 (https://bugs.freedesktop.org/show_bug.cgi?id=29389)? The latest 2.6.36 RCs should already have the kernel parameter to disable polling. Giacomo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 13.59 +0200, GhePeU ha scritto: > Il giorno dom, 02/05/2010 alle 20.46 +1000, Dave Airlie ha scritto: > > On Sun, May 2, 2010 at 7:42 PM, GhePeU wrote: > > > Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: > > >> On Sat, May 1, 2010 at 10:42 PM, GhePeU wrote: > > >> > > > >> > Would it be possible to add a module option to disable tv load > > >> > detection? As things are now I must always change back the resolution > > >> > to > > >> > 1440x900 and disable the TV. > > >> > > >> try booting with video=TV-1:d > > > > oh try video=DIN-1:d > > > > or S-video-1:d, have a look in /sys/class/drm when booted for the correct > > one. > > > > Dave. > > /sys/class/drm lists "card0-SVIDEO-1", dmesg has "S-video" and the > encoder is "TV1". I booted with "video=SVIDEO-1:d", "video=S-video:d", > "video=TV1:d" and finally "video=S-video-1:d" but none of them worked. > > I'll look to the source code when I'll have the time. > > Giacomo > Looking to radeon_connector.c I found that TV load detection had already been disabled for some other chipsets because it wasn't always reliable. I just added my card's family to the check (patch attached) and now my problem's gone. Disabling TV detection for the entire family is probably overkill, just blacklisting my card (a Radeon Sapphire X550 Silent, 1002:5b63) would've been enough, is there another place where this quirk could be added? Giacomo -- next part -- A non-text attachment was scrubbed... Name: RV380-disable-tv-load-detection.patch Type: text/x-patch Size: 622 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100502/fa5179c1/attachment.bin>
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 20.46 +1000, Dave Airlie ha scritto: > On Sun, May 2, 2010 at 7:42 PM, GhePeU wrote: > > Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: > >> On Sat, May 1, 2010 at 10:42 PM, GhePeU wrote: > >> > Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: > >> >> On Tue, Apr 27, 2010 at 6:24 PM, GhePeU wrote: > >> >> > Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: > >> >> >> On Tue, Apr 27, 2010 at 5:30 PM, GhePeU > >> >> >> wrote: > >> >> >> > Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha > >> >> >> > scritto: > >> >> >> >> >From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 > >> >> >> >> >00:00:00 2001 > >> >> >> >> From: Alex Deucher > >> >> >> >> Date: Thu, 15 Apr 2010 13:31:12 -0400 > >> >> >> >> Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver > >> >> >> > > >> >> >> > Hi, > >> >> >> > > >> >> >> > a few days ago I upgraded to the last 2.6.34 rc kernel and found > >> >> >> > that with > >> >> >> > KMS both the console and X were using a 800x600 resolution instead > >> >> >> > of my LCD > >> >> >> > display's native resolution of 1440x900 who was selected by > >> >> >> > default with > >> >> >> > 2.6.33 and previous kernels. > >> >> >> > > >> >> >> > I tracked the problem to this patch, which causes the same issues > >> >> >> > also > >> >> >> > when manually applied to 2.6.33: apparently the kms radeon driver > >> >> >> > wrongly detects a TV connected to my card (I don't have one, only > >> >> >> > a LCD > >> >> >> > display connected to the DVI port) and forces the TV default > >> >> >> > resolution > >> >> >> > for all the outputs. > >> >> >> > >> >> >> You issue is not related to the patch. What the patch does is allow > >> >> >> you to use the digital part of DVI plus TV at the same time. The > >> >> >> analog part of the DVI port and the TV share the same DAC so they > >> >> >> can't be used at the same time. Prior to the patch, both the TV and > >> >> >> DVI were detected as attached, but the TV was always disabled since > >> >> >> it > >> >> >> was wrongly seen as conflicting with the DVI. > >> >> >> > >> >> >> Your issue is actually a matter of load detection for TV not always > >> >> >> being reliable. I don't know what a proper fix would be. We could > >> >> >> disable load detection for TV to avoid false positives, but that > >> >> >> would > >> >> >> prevent automatic detection of TV which does work in most cases. > >> >> >> > >> >> >> Alex > >> >> >> > >> >> > > >> >> > With UMS however I don't have this problem, is the logic different? > >> >> > > >> >> > Shouldn't the driver behavior with KMS be the same, in this case? At > >> >> > least there wouldn't be (apparent) regressions like the one I'm > >> >> > experiencing. > >> >> > > >> >> > >> >> UMS does not enable load detection on TV by default while KMS does, > >> >> the difference being KMS provides both the console and X so you want > >> >> to make sure you put something up on whatever monitors or tvs happen > >> >> to be attached. I'm not sure what the best answer is here. > >> >> > >> >> Alex > >> > > >> > Would it be possible to add a module option to disable tv load > >> > detection? As things are now I must always change back the resolution to > >> > 1440x900 and disable the TV. > >> > >> try booting with video=TV-1:d > > oh try video=DIN-1:d > > or S-video-1:d, have a look in /sys/class/drm when booted for the correct one. > > Dave. /sys/class/drm lists "card0-SVIDEO-1", dmesg has "S-video" and the encoder is "TV1". I booted with "video=SVIDEO-1:d", "video=S-video:d", "video=TV1:d" and finally "video=S-video-1:d" but none of them worked. I'll look to the source code when I'll have the time. Giacomo
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: > On Sat, May 1, 2010 at 10:42 PM, GhePeU wrote: > > Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: > >> On Tue, Apr 27, 2010 at 6:24 PM, GhePeU wrote: > >> > Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: > >> >> On Tue, Apr 27, 2010 at 5:30 PM, GhePeU wrote: > >> >> > Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: > >> >> >> >From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 > >> >> >> >2001 > >> >> >> From: Alex Deucher > >> >> >> Date: Thu, 15 Apr 2010 13:31:12 -0400 > >> >> >> Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver > >> >> > > >> >> > Hi, > >> >> > > >> >> > a few days ago I upgraded to the last 2.6.34 rc kernel and found that > >> >> > with > >> >> > KMS both the console and X were using a 800x600 resolution instead of > >> >> > my LCD > >> >> > display's native resolution of 1440x900 who was selected by default > >> >> > with > >> >> > 2.6.33 and previous kernels. > >> >> > > >> >> > I tracked the problem to this patch, which causes the same issues also > >> >> > when manually applied to 2.6.33: apparently the kms radeon driver > >> >> > wrongly detects a TV connected to my card (I don't have one, only a > >> >> > LCD > >> >> > display connected to the DVI port) and forces the TV default > >> >> > resolution > >> >> > for all the outputs. > >> >> > >> >> You issue is not related to the patch. What the patch does is allow > >> >> you to use the digital part of DVI plus TV at the same time. The > >> >> analog part of the DVI port and the TV share the same DAC so they > >> >> can't be used at the same time. Prior to the patch, both the TV and > >> >> DVI were detected as attached, but the TV was always disabled since it > >> >> was wrongly seen as conflicting with the DVI. > >> >> > >> >> Your issue is actually a matter of load detection for TV not always > >> >> being reliable. I don't know what a proper fix would be. We could > >> >> disable load detection for TV to avoid false positives, but that would > >> >> prevent automatic detection of TV which does work in most cases. > >> >> > >> >> Alex > >> >> > >> > > >> > With UMS however I don't have this problem, is the logic different? > >> > > >> > Shouldn't the driver behavior with KMS be the same, in this case? At > >> > least there wouldn't be (apparent) regressions like the one I'm > >> > experiencing. > >> > > >> > >> UMS does not enable load detection on TV by default while KMS does, > >> the difference being KMS provides both the console and X so you want > >> to make sure you put something up on whatever monitors or tvs happen > >> to be attached. I'm not sure what the best answer is here. > >> > >> Alex > > > > Would it be possible to add a module option to disable tv load > > detection? As things are now I must always change back the resolution to > > 1440x900 and disable the TV. > > try booting with video=TV-1:d > > Dave. Didn't work, both console and X started at 800x600. Giacomo
Re: [PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: On Sat, May 1, 2010 at 10:42 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 6:24 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 5:30 PM, GhePeU ghe...@virgilio.it wrote: Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Thu, 15 Apr 2010 13:31:12 -0400 Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver Hi, a few days ago I upgraded to the last 2.6.34 rc kernel and found that with KMS both the console and X were using a 800x600 resolution instead of my LCD display's native resolution of 1440x900 who was selected by default with 2.6.33 and previous kernels. I tracked the problem to this patch, which causes the same issues also when manually applied to 2.6.33: apparently the kms radeon driver wrongly detects a TV connected to my card (I don't have one, only a LCD display connected to the DVI port) and forces the TV default resolution for all the outputs. You issue is not related to the patch. What the patch does is allow you to use the digital part of DVI plus TV at the same time. The analog part of the DVI port and the TV share the same DAC so they can't be used at the same time. Prior to the patch, both the TV and DVI were detected as attached, but the TV was always disabled since it was wrongly seen as conflicting with the DVI. Your issue is actually a matter of load detection for TV not always being reliable. I don't know what a proper fix would be. We could disable load detection for TV to avoid false positives, but that would prevent automatic detection of TV which does work in most cases. Alex With UMS however I don't have this problem, is the logic different? Shouldn't the driver behavior with KMS be the same, in this case? At least there wouldn't be (apparent) regressions like the one I'm experiencing. UMS does not enable load detection on TV by default while KMS does, the difference being KMS provides both the console and X so you want to make sure you put something up on whatever monitors or tvs happen to be attached. I'm not sure what the best answer is here. Alex Would it be possible to add a module option to disable tv load detection? As things are now I must always change back the resolution to 1440x900 and disable the TV. try booting with video=TV-1:d Dave. Didn't work, both console and X started at 800x600. Giacomo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 20.46 +1000, Dave Airlie ha scritto: On Sun, May 2, 2010 at 7:42 PM, GhePeU ghe...@virgilio.it wrote: Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: On Sat, May 1, 2010 at 10:42 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 6:24 PM, GhePeU ghe...@virgilio.it wrote: Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: On Tue, Apr 27, 2010 at 5:30 PM, GhePeU ghe...@virgilio.it wrote: Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Thu, 15 Apr 2010 13:31:12 -0400 Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver Hi, a few days ago I upgraded to the last 2.6.34 rc kernel and found that with KMS both the console and X were using a 800x600 resolution instead of my LCD display's native resolution of 1440x900 who was selected by default with 2.6.33 and previous kernels. I tracked the problem to this patch, which causes the same issues also when manually applied to 2.6.33: apparently the kms radeon driver wrongly detects a TV connected to my card (I don't have one, only a LCD display connected to the DVI port) and forces the TV default resolution for all the outputs. You issue is not related to the patch. What the patch does is allow you to use the digital part of DVI plus TV at the same time. The analog part of the DVI port and the TV share the same DAC so they can't be used at the same time. Prior to the patch, both the TV and DVI were detected as attached, but the TV was always disabled since it was wrongly seen as conflicting with the DVI. Your issue is actually a matter of load detection for TV not always being reliable. I don't know what a proper fix would be. We could disable load detection for TV to avoid false positives, but that would prevent automatic detection of TV which does work in most cases. Alex With UMS however I don't have this problem, is the logic different? Shouldn't the driver behavior with KMS be the same, in this case? At least there wouldn't be (apparent) regressions like the one I'm experiencing. UMS does not enable load detection on TV by default while KMS does, the difference being KMS provides both the console and X so you want to make sure you put something up on whatever monitors or tvs happen to be attached. I'm not sure what the best answer is here. Alex Would it be possible to add a module option to disable tv load detection? As things are now I must always change back the resolution to 1440x900 and disable the TV. try booting with video=TV-1:d oh try video=DIN-1:d or S-video-1:d, have a look in /sys/class/drm when booted for the correct one. Dave. /sys/class/drm lists card0-SVIDEO-1, dmesg has S-video and the encoder is TV1. I booted with video=SVIDEO-1:d, video=S-video:d, video=TV1:d and finally video=S-video-1:d but none of them worked. I'll look to the source code when I'll have the time. Giacomo ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno dom, 02/05/2010 alle 13.59 +0200, GhePeU ha scritto: Il giorno dom, 02/05/2010 alle 20.46 +1000, Dave Airlie ha scritto: On Sun, May 2, 2010 at 7:42 PM, GhePeU ghe...@virgilio.it wrote: Il giorno dom, 02/05/2010 alle 19.11 +1000, Dave Airlie ha scritto: On Sat, May 1, 2010 at 10:42 PM, GhePeU ghe...@virgilio.it wrote: Would it be possible to add a module option to disable tv load detection? As things are now I must always change back the resolution to 1440x900 and disable the TV. try booting with video=TV-1:d oh try video=DIN-1:d or S-video-1:d, have a look in /sys/class/drm when booted for the correct one. Dave. /sys/class/drm lists card0-SVIDEO-1, dmesg has S-video and the encoder is TV1. I booted with video=SVIDEO-1:d, video=S-video:d, video=TV1:d and finally video=S-video-1:d but none of them worked. I'll look to the source code when I'll have the time. Giacomo Looking to radeon_connector.c I found that TV load detection had already been disabled for some other chipsets because it wasn't always reliable. I just added my card's family to the check (patch attached) and now my problem's gone. Disabling TV detection for the entire family is probably overkill, just blacklisting my card (a Radeon Sapphire X550 Silent, 1002:5b63) would've been enough, is there another place where this quirk could be added? Giacomo --- a/drivers/gpu/drm/radeon/radeon_connectors.c 2010-05-02 16:28:30.123432476 +0200 +++ b/drivers/gpu/drm/radeon/radeon_connectors.c 2010-05-02 17:46:25.026128098 +0200 @@ -1337,7 +1337,7 @@ * found a way to make load detect reliable on those * chipset, thus just disable it for TV. */ - if (rdev-family == CHIP_RS400 || rdev-family == CHIP_RS480) + if (rdev-family == CHIP_RS400 || rdev-family == CHIP_RS480 || rdev-family == CHIP_RV380) radeon_connector-dac_load_detect = false; drm_connector_attach_property(radeon_connector-base, rdev-mode_info.load_detect_property, ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno mar, 27/04/2010 alle 18.57 -0400, Alex Deucher ha scritto: > On Tue, Apr 27, 2010 at 6:24 PM, GhePeU wrote: > > Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: > >> On Tue, Apr 27, 2010 at 5:30 PM, GhePeU wrote: > >> > Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: > >> >> >From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 > >> >> From: Alex Deucher > >> >> Date: Thu, 15 Apr 2010 13:31:12 -0400 > >> >> Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver > >> > > >> > Hi, > >> > > >> > a few days ago I upgraded to the last 2.6.34 rc kernel and found that > >> > with > >> > KMS both the console and X were using a 800x600 resolution instead of my > >> > LCD > >> > display's native resolution of 1440x900 who was selected by default with > >> > 2.6.33 and previous kernels. > >> > > >> > I tracked the problem to this patch, which causes the same issues also > >> > when manually applied to 2.6.33: apparently the kms radeon driver > >> > wrongly detects a TV connected to my card (I don't have one, only a LCD > >> > display connected to the DVI port) and forces the TV default resolution > >> > for all the outputs. > >> > >> You issue is not related to the patch. What the patch does is allow > >> you to use the digital part of DVI plus TV at the same time. The > >> analog part of the DVI port and the TV share the same DAC so they > >> can't be used at the same time. Prior to the patch, both the TV and > >> DVI were detected as attached, but the TV was always disabled since it > >> was wrongly seen as conflicting with the DVI. > >> > >> Your issue is actually a matter of load detection for TV not always > >> being reliable. I don't know what a proper fix would be. We could > >> disable load detection for TV to avoid false positives, but that would > >> prevent automatic detection of TV which does work in most cases. > >> > >> Alex > >> > > > > With UMS however I don't have this problem, is the logic different? > > > > Shouldn't the driver behavior with KMS be the same, in this case? At > > least there wouldn't be (apparent) regressions like the one I'm > > experiencing. > > > > UMS does not enable load detection on TV by default while KMS does, > the difference being KMS provides both the console and X so you want > to make sure you put something up on whatever monitors or tvs happen > to be attached. I'm not sure what the best answer is here. > > Alex Would it be possible to add a module option to disable tv load detection? As things are now I must always change back the resolution to 1440x900 and disable the TV. By the way I just tested "radeon.tv=0" and both 2.6.33 and 2.6.34 rc5 fail with a "BUG: unable to handle kernel NULL pointer dereference". Syslog output attached. Giacomo -- next part -- A non-text attachment was scrubbed... Name: bug-2.6.33.log Type: text/x-log Size: 7355 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100501/f0915d8d/attachment.bin> -- next part -- A non-text attachment was scrubbed... Name: bug-2.6.34rc5.log Type: text/x-log Size: 7896 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100501/f0915d8d/attachment-0001.bin>
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno mar, 27/04/2010 alle 18.11 -0400, Alex Deucher ha scritto: > On Tue, Apr 27, 2010 at 5:30 PM, GhePeU wrote: > > Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: > >> >From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 > >> From: Alex Deucher > >> Date: Thu, 15 Apr 2010 13:31:12 -0400 > >> Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver > > > > Hi, > > > > a few days ago I upgraded to the last 2.6.34 rc kernel and found that with > > KMS both the console and X were using a 800x600 resolution instead of my LCD > > display's native resolution of 1440x900 who was selected by default with > > 2.6.33 and previous kernels. > > > > I tracked the problem to this patch, which causes the same issues also > > when manually applied to 2.6.33: apparently the kms radeon driver > > wrongly detects a TV connected to my card (I don't have one, only a LCD > > display connected to the DVI port) and forces the TV default resolution > > for all the outputs. > > You issue is not related to the patch. What the patch does is allow > you to use the digital part of DVI plus TV at the same time. The > analog part of the DVI port and the TV share the same DAC so they > can't be used at the same time. Prior to the patch, both the TV and > DVI were detected as attached, but the TV was always disabled since it > was wrongly seen as conflicting with the DVI. > > Your issue is actually a matter of load detection for TV not always > being reliable. I don't know what a proper fix would be. We could > disable load detection for TV to avoid false positives, but that would > prevent automatic detection of TV which does work in most cases. > > Alex > With UMS however I don't have this problem, is the logic different? Shouldn't the driver behavior with KMS be the same, in this case? At least there wouldn't be (apparent) regressions like the one I'm experiencing. Giacomo
[PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: > >From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 > From: Alex Deucher > Date: Thu, 15 Apr 2010 13:31:12 -0400 > Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver > > On systems with the tv dac shared between DVI and TV, > we can only use the dac for one of the connectors. > However, when using a digital monitor on the DVI port, > you can use the dac for the TV connector just fine. > Check the use_digital status when resolving the conflict. > > Fixes fdo bug 27649, possibly others. > > Signed-off-by: Alex Deucher > Cc: stable [resending because I suspect something went wrong the first time, sorry if it's a duplicate] Hi, a few days ago I upgraded to the last 2.6.34 rc kernel and found that with KMS both the console and X were using a 800x600 resolution instead of my LCD display's native resolution of 1440x900 who was selected by default with 2.6.33 and previous kernels. 1440x900 also disappeared from the available resolution listed by GNOME display utility, and I could enable it again only with the xrandr command line tool. I tracked the problem to this patch, which causes the same issues also when manually applied to 2.6.33: apparently the kms radeon driver wrongly detects a TV connected to my card (I don't have one, only a LCD display connected to the DVI port) and forces the TV default resolution for all the outputs. Attached to the email the xrandr output I get with 2.6.33 and 2.6.34 and pasted after the actual text are the relevant portions of the dmesg output of 2.6.34. I'm using a Radeon RV370 card. Please tell me if you need other information. Best regards, Giacomo dmesg: [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RV380 0x1002:0x5B63). [drm] register mmio base: 0xFD7F [drm] register mmio size: 65536 [drm] GPU reset succeed (RBBM_STATUS=0x0140) [drm] 1 Power State(s) [drm] State 0 Default (default) [drm] 16 PCIE Lanes [drm] 1 Clock Mode(s) [drm] 0 engine/memory: 40/25 [drm] radeon: power management initialized [drm] Generation 2 PCI interface, using max accessible memory [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 1030236 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: 1 quad pipes, 1 Z pipes initialized. [drm] PCIE GART of 512M enabled (table at 0xD004). [drm] radeon: cp idle (0x1C03) [drm] Loading R300 Microcode platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin [drm] radeon: ring at 0xB000 [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Default TV standard: NTSC [drm] 27.0 MHz TV ref clk [drm] DFP table revision: 4 [drm] Default TV standard: NTSC [drm] 27.0 MHz TV ref clk [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 [drm] Encoders: [drm] CRT1: INTERNAL_DAC1 [drm] Connector 1: [drm] DVI-I [drm] HPD1 [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 [drm] Encoders: [drm] CRT2: INTERNAL_DAC2 [drm] DFP1: INTERNAL_TMDS1 [drm] Connector 2: [drm] S-video [drm] Encoders: [drm] TV1: INTERNAL_DAC2 [drm] fb mappable at 0xD00C [drm] vram apper at 0xD000 [drm] size 5184000 [drm] fb depth is 24 [drm]pitch is 5760 [drm] crtc 1 is connected to a TV Console: switching to colour frame buffer device 100x37 fb0: radeondrmfb frame buffer device registered panic notifier [drm] Initialized radeon 2.3.0 20080528 for :05:00.0 on minor 0 -- next part -- Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1440 x 1440 VGA-0 disconnected (normal left inverted right x axis y axis) DVI-0 connected 1440x900+0+0 (normal left inverted right x axis y axis) 410mm x 257mm 1440x900 59.9*+ 75.0 59.9 1280x1024 75.0 60.0 1280x960 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48075.0 72.8 66.7 59.9 720x40070.1 S-video disconnected (normal left inverted right x axis y axis) Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1440 x 1440 VGA-0 disconnected (normal left inverted right x axis y axis) Identifier: 0x52 Timestamp: 36419 Subpixel: no subpixels Clones: DVI-0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: load_detection: 1 (0x0001) range:
Re: [PATCH] drm/radeon/kms: fix tv dac conflict resolver
Il giorno gio, 15/04/2010 alle 13.41 -0400, Alex Deucher ha scritto: From 837feb147c531219c7315857a6f17e145af8f750 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Thu, 15 Apr 2010 13:31:12 -0400 Subject: [PATCH] drm/radeon/kms: fix tv dac conflict resolver On systems with the tv dac shared between DVI and TV, we can only use the dac for one of the connectors. However, when using a digital monitor on the DVI port, you can use the dac for the TV connector just fine. Check the use_digital status when resolving the conflict. Fixes fdo bug 27649, possibly others. Signed-off-by: Alex Deucher alexdeuc...@gmail.com Cc: stable sta...@kernel.org [resending because I suspect something went wrong the first time, sorry if it's a duplicate] Hi, a few days ago I upgraded to the last 2.6.34 rc kernel and found that with KMS both the console and X were using a 800x600 resolution instead of my LCD display's native resolution of 1440x900 who was selected by default with 2.6.33 and previous kernels. 1440x900 also disappeared from the available resolution listed by GNOME display utility, and I could enable it again only with the xrandr command line tool. I tracked the problem to this patch, which causes the same issues also when manually applied to 2.6.33: apparently the kms radeon driver wrongly detects a TV connected to my card (I don't have one, only a LCD display connected to the DVI port) and forces the TV default resolution for all the outputs. Attached to the email the xrandr output I get with 2.6.33 and 2.6.34 and pasted after the actual text are the relevant portions of the dmesg output of 2.6.34. I'm using a Radeon RV370 card. Please tell me if you need other information. Best regards, Giacomo dmesg: [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm] initializing kernel modesetting (RV380 0x1002:0x5B63). [drm] register mmio base: 0xFD7F [drm] register mmio size: 65536 [drm] GPU reset succeed (RBBM_STATUS=0x0140) [drm] 1 Power State(s) [drm] State 0 Default (default) [drm] 16 PCIE Lanes [drm] 1 Clock Mode(s) [drm] 0 engine/memory: 40/25 [drm] radeon: power management initialized [drm] Generation 2 PCI interface, using max accessible memory [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 1030236 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: 1 quad pipes, 1 Z pipes initialized. [drm] PCIE GART of 512M enabled (table at 0xD004). [drm] radeon: cp idle (0x1C03) [drm] Loading R300 Microcode platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin [drm] radeon: ring at 0xB000 [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Default TV standard: NTSC [drm] 27.0 MHz TV ref clk [drm] DFP table revision: 4 [drm] Default TV standard: NTSC [drm] 27.0 MHz TV ref clk [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 [drm] Encoders: [drm] CRT1: INTERNAL_DAC1 [drm] Connector 1: [drm] DVI-I [drm] HPD1 [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 [drm] Encoders: [drm] CRT2: INTERNAL_DAC2 [drm] DFP1: INTERNAL_TMDS1 [drm] Connector 2: [drm] S-video [drm] Encoders: [drm] TV1: INTERNAL_DAC2 [drm] fb mappable at 0xD00C [drm] vram apper at 0xD000 [drm] size 5184000 [drm] fb depth is 24 [drm]pitch is 5760 [drm] crtc 1 is connected to a TV Console: switching to colour frame buffer device 100x37 fb0: radeondrmfb frame buffer device registered panic notifier [drm] Initialized radeon 2.3.0 20080528 for :05:00.0 on minor 0 Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1440 x 1440 VGA-0 disconnected (normal left inverted right x axis y axis) DVI-0 connected 1440x900+0+0 (normal left inverted right x axis y axis) 410mm x 257mm 1440x900 59.9*+ 75.0 59.9 1280x1024 75.0 60.0 1280x960 60.0 1152x864 75.0 1024x768 75.0 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48075.0 72.8 66.7 59.9 720x40070.1 S-video disconnected (normal left inverted right x axis y axis) Screen 0: minimum 320 x 200, current 1440 x 900, maximum 1440 x 1440 VGA-0 disconnected (normal left inverted right x axis y axis) Identifier: 0x52 Timestamp: 36419 Subpixel: no subpixels Clones: DVI-0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: load_detection: 1 (0x0001) range:
