[Bug 38018] New: Implementation error: bad format in _mesa_pack_rgba_span
https://bugs.freedesktop.org/show_bug.cgi?id=38018 Summary: Implementation error: bad format in _mesa_pack_rgba_span Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: minor Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: gm.potato.ul at gmail.com Created an attachment (id=47634) --> (https://bugs.freedesktop.org/attachment.cgi?id=47634) dmesg and glxinfo catenated together When running the freeware OpenGL 2.1 title Savage 2, the following two lines of text show up on the console while the game is running. The two lines repeat exactly seven times. Only one functional anomaly was observed: when trying to quit the game, only a SIGKILL could terminate the process (SIGTERM / SIGINT were not enough). Performance is fairly good and there are no observable rendering errors, so I am marking this as MINOR. The message is: Please report at bugs.freedesktop.org Mesa 7.11-devel implementation error: bad format in _mesa_pack_rgba_span dmesg and glxinfo are attached. Summary: (1) Weird intel-iommu warnings on bootup (2) Hardware: Radeon HD5970 (3) Git version of mesa: git-c2e6590 (4) libdrm, DDX and linux from git (5) Xorg server from Ubuntu 11.04, version 1.10.1; pixman 0.20.2 Non-standard radeon DDX options: Option "SwapbuffersWait" "off" Option "ColorTiling" "on" Option "EnablePageFlip" "on" Option "EXAVSync" "off" Option "DynamicPM" "on" -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Regression: Borked display on second output with Intel G45 in 3.0-rc2
* Nick Bowler -- Monday 06 June 2011:
> After upgrading to 3.0-rc2, my second display is no longer working
> correctly on a desktop with an Intel G45 graphics chip.
[...]
> What I do know is that the problem was originally introduced by
> 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
> "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
That's apparently the bug that I've submitted a patch for on 2011/5/31:
https://lkml.org/lkml/2011/5/31/393
I assume/hope it's still in someone's queue.
m.
Semantics of the 'dumb' interface
> I think the intel driver forces a reset to the system scanout on release. I've > actually never found a test to indicate it was completely necessary on > other GPUs I need to force this on the GMA500 because we want some kind of sane scanout left and the nice guys at Dell decided the Mini 10 didn't actually need a sysrq key so sysrq-V isn't going to help. On the bright side GEM and the dumb kms stuff now seem to work with a new device id added to libkms and a daft bug in libkms dumb.c fixed (if you report a 32bit fb type, you probably want to allocate a 32bit fb not a 16bit one) Alan
[PATCH] drm/radeon/kms: disable hdmi audio by default
The current RE'd code causes blank screens and display problems on a lot of systems. So disable it by default for now. It can still be enabled by setting the audio parameter to 1. E.g.: radeon.audio=1 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38010 https://bugs.freedesktop.org/show_bug.cgi?id=27731 https://bugs.freedesktop.org/show_bug.cgi?id=35970 https://bugs.freedesktop.org/show_bug.cgi?id=26195 and many other reported problems. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/radeon_drv.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 1d33060..73dfbe8 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -113,7 +113,7 @@ int radeon_benchmarking = 0; int radeon_testing = 0; int radeon_connector_table = 0; int radeon_tv = 1; -int radeon_audio = 1; +int radeon_audio = 0; int radeon_disp_priority = 0; int radeon_hw_i2c = 0; int radeon_pcie_gen2 = 0; @@ -151,7 +151,7 @@ module_param_named(connector_table, radeon_connector_table, int, 0444); MODULE_PARM_DESC(tv, "TV enable (0 = disable)"); module_param_named(tv, radeon_tv, int, 0444); -MODULE_PARM_DESC(audio, "Audio enable (0 = disable)"); +MODULE_PARM_DESC(audio, "Audio enable (1 = enable)"); module_param_named(audio, radeon_audio, int, 0444); MODULE_PARM_DESC(disp_priority, "Display Priority (0 = auto, 1 = normal, 2 = high)"); -- 1.7.1.1
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #10 from Maggioni Marcello 2011-06-06 17:10:42 PDT --- Hi, after applying the patch the problem seems to be still there ... my card is a Radeon 5850. The lights have a white halo surrounding them flickering. Also , the white area at the bottom of the screen problem is still present in fullscreen mode. It was just scene dependent and I thought it was gone because I checked in a scene in which it wasn't present. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Intel-gfx] drivers/drm/i915 maintenance process
On Mon, 6 Jun 2011 16:30:25 -0700 Jesse Barnes wrote: > On Mon, 06 Jun 2011 16:24:46 -0700 > Keith Packard wrote: > > > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > virtuousgeek.org> wrote: > > > > > Can you keep drm-intel-next fairly up to date with respect to the fixes > > > branch? I.e. keep it a superset of drm-intel-fixes for the most part? > > > > Yes, I wanted to do that now, but -fixes is not a fast-forward from > > -next and I thought I shouldn't be doing rebases. > > You shouldn't if your downstream is using git trees and you're pulling > from them, but it depends on your downstream. In my particular case, > I'm ok with rebases if it means I get fixes. :) Oh and the other big reason is testing. rebase generally voids previous testing since you have new bits, so Linus really hates to see a rebase just before a pull request, and I think Dave does too. But rebasing for good reason (e.g. to make your -next branch a superset of your -fixes branch) on occasion is fine. -- Jesse Barnes, Intel Open Source Technology Center
drivers/drm/i915 maintenance process
On Mon, 06 Jun 2011 16:24:46 -0700 Keith Packard wrote: > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes > wrote: > > > Can you keep drm-intel-next fairly up to date with respect to the fixes > > branch? I.e. keep it a superset of drm-intel-fixes for the most part? > > Yes, I wanted to do that now, but -fixes is not a fast-forward from > -next and I thought I shouldn't be doing rebases. You shouldn't if your downstream is using git trees and you're pulling from them, but it depends on your downstream. In my particular case, I'm ok with rebases if it means I get fixes. :) -- Jesse Barnes, Intel Open Source Technology Center
drivers/drm/i915 maintenance process
On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes wrote: > Can you keep drm-intel-next fairly up to date with respect to the fixes > branch? I.e. keep it a superset of drm-intel-fixes for the most part? Yes, I wanted to do that now, but -fixes is not a fast-forward from -next and I thought I shouldn't be doing rebases. > In PCI-land, this means re-basing my -next tree periodically before the > merge window opens (though not right before the merge window unless > something unexpected happens, like a patch needing to be dropped; in > that case I'll delay the merge window push a bit to allow for more > testing). If a rebase around -RC1 is reasonable, then I'll do that now and move changes over to that. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110606/2a9c9038/attachment-0001.pgp>
Flat address space with gGTT / ppGTT
Hello all, I saw at some point that per-process GTT (ppGTT) may be (or is already) implemented to handle paging. Right now, I am investigating some flat space addressing (ab)using surface states. The idea is to create a surface state (raw buffer only, this is GPGPU stuff) as big enough to cover the entire address space such that I will only manipulate offsets as pointers in this surface instead of dealing with both offsets and surface IDs (in other words, segmented address space). My concern is relative to the way bo buffers are mapped. Basically, I must be sure that _all_ of them are either mapped using ppGTT or GTT. Otherwise, this will also bring another form of segmentation. If ppGTT is implemented or will be implemented, will there be anyway to know how a bo is mapped? Cheers, Ben
[Bug 38010] DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 --- Comment #3 from darkbasic 2011-06-06 14:18:41 PDT --- > Does booting with radeon.audio=0 on the kernel command line in grub help? OMG you had been faster than light, and it worked! Consider this card does not even have an HDMI output! Thank you very much P.S. Should I close this? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38010] DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 --- Comment #2 from darkbasic 2011-06-06 14:13:48 PDT --- Created an attachment (id=47623) --> (https://bugs.freedesktop.org/attachment.cgi?id=47623) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38010] DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 --- Comment #1 from Alex Deucher 2011-06-06 14:13:06 PDT --- Does booting with radeon.audio=0 on the kernel command line in grub help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38010] New: DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 Summary: DVI output not working with radeon on RV610 Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: darkbasic4 at gmail.com Created an attachment (id=47622) --> (https://bugs.freedesktop.org/attachment.cgi?id=47622) dmesg Hi, I have an RV610 card attached to an LG 22LH2000. The LG 22LH2000 has a 1366x768 native resolution and does have VGA and HDMI but not DVI. The Radeon HD2400 does have VGA and DVI but not HDMI, so I'm using a DVI-HDMI converter. When I use the VGA output everything works fine, but I don't get a 1:1 pixel mapping because I have to set a 1360x768 or 1368x768 resolution and the monitor is not smart enough when using vga. Instead when I attach the monitor to my laptop's Intel GMA45 HDMI output I can get a 1:1 pixel mapping even using a 1360x768 resolution. Unfortunately when using the HD2400 DVI output the monitor does not show anything, at least after loading the radeon module. In fact when loading the bios or starting grub the DVI output works flawlessly. nomodeset does not help. I even tried setting another resolution with xrandr (it automatically set 1920x1080i, but I tried 1360x768, 1280x800, 1024x768 and 800x600 and it still does not work). Distro is Debian Unstable amd64 with kernel 2.6.39 and xorg-edgers ppa. It's the only monitor I will be able to use for a couple of months, it's critical for me to get it working. Thank you -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Regression: Borked display on second output with Intel G45 in 3.0-rc2
On 2011-06-06 19:20 +0200, Melchior FRANZ wrote:
> * Nick Bowler -- Monday 06 June 2011:
> > After upgrading to 3.0-rc2, my second display is no longer working
> > correctly on a desktop with an Intel G45 graphics chip.
> [...]
> > What I do know is that the problem was originally introduced by
> > 49183b2818de ("drm/i915: Only enable the plane after setting the fb
> > base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
> > "drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
> > The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
> > of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
>
> That's apparently the bug that I've submitted a patch for on 2011/5/31:
> https://lkml.org/lkml/2011/5/31/393
> I assume/hope it's still in someone's queue.
Yup, that fixes it right up, thanks.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
drivers/drm/i915 maintenance process
On Sat, 04 Jun 2011 23:05:23 -0700 "Keith Packard" wrote: > 1) drm-intel-next > > This contains work destined for the 'next' release, it may include > new functionality and performance enhancements. It may also cause > regressions on some hardware. The tip of this tree will be sent > to Dave Airlie for inclusion in the kernel during the next > merge window. I've already sent all of what is on this branch > to him for 3.0 > > This tree should be tested during the development process to try and > catch bugs and regressions before they are merged. The most critical > time for testing this is just *before* the release of the current RC > kernel version as that is when it should have most of the code > planned for the *next* release. > > 2) drm-intel-fixes > > This contains bug fixes after the merge window has closed. I will > fast-forwarded to each RC when possible so that we test the fully > integrated kernel for regressions. > > This tree should be tested during the stabilization process after RC1 > comes out as patches are applied. Can you keep drm-intel-next fairly up to date with respect to the fixes branch? I.e. keep it a superset of drm-intel-fixes for the most part? In PCI-land, this means re-basing my -next tree periodically before the merge window opens (though not right before the merge window unless something unexpected happens, like a patch needing to be dropped; in that case I'll delay the merge window push a bit to allow for more testing). Downstream PCI developers requested this since it makes feature development much easier (you get all the bug fixes destined for Linus while working on a new feature for the next window), and as a downstream gfx developer I'd like to see this on the Intel side as well, unless other developers have big objections... Thanks, -- Jesse Barnes, Intel Open Source Technology Center
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #9 from Pierre-Eric Pelloux-Prayer 2011-06-06 13:28:16 PDT --- Created an attachment (id=47621) View: https://bugs.freedesktop.org/attachment.cgi?id=47621 Review: https://bugs.freedesktop.org/review?bug=37028=47621 proposed patch Could you please try this patch ? It should fix the issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Regression: Borked display on second output with Intel G45 in 3.0-rc2
On Mon, 6 Jun 2011 19:20:06 +0200, Melchior FRANZ wrote: > That's apparently the bug that I've submitted a patch for on 2011/5/31: > https://lkml.org/lkml/2011/5/31/393 > I assume/hope it's still in someone's queue. Yeah, we "shouldn't" need to call intel_enable_plane from i9xx_crtc_mode_set as it is called immediately afterwards from i9xx_crtc_enable. In any case, there's a bogus call in ironlake_crtc_mode_set which clearly belongs in i9xx_crtc_mode_set: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 81a9059..aa43e7b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4687,6 +4687,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); + intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); @@ -5217,8 +5218,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); - if (!HAS_PCH_SPLIT(dev)) - intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); We need to figure out why this call (in i9xx_crtc_mode_set) is required, but that will require finding hardware that reproduces the bug and fixing it there. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110606/5d412baf/attachment.pgp>
Regression: Borked display on second output with Intel G45 in 3.0-rc2
After upgrading to 3.0-rc2, my second display is no longer working
correctly on a desktop with an Intel G45 graphics chip. The system has
two displays, one connected by HDMI and the other by VGA.
Both displays work fine in the console; the troubles begin after
starting X. It *looks* as if one of the displays is still scanning out
from the old framebuffer: what I see on the VGA monitor after starting X
is a black screen with a console cursor at the top -- this is just like
an empty VT except that the cursor is not blinking. If I switch to VT 1
and then back to X, the display contains all the bootup text that was on
VT 1. In any case, the mouse cursor works properly on the display.
There are no unusual messages in dmesg or the Xorg log in any case.
If I fiddle around with the xrandr tool (e.g. do an xrandr --output VGA1
--same-as HDMI1 && xrandr --output VGA1 --right-of VGA1) , it's possible
to get both displays showing the right thing. But then if I switch back
to the console, I end up with one display showing the console text and
the other is still showing my X session! (In this instance, the VGA was
working and the HDMI was showing the wrong thing).
This is a regression from 2.6.39, but that's not the whole story: this
problem appears to have been introduced very briefly late in the 2.6.39
-rc cycle and subsequently fixed on mainline. It then reappeared during
the 3.0 merge window. Unfortunately, this fact seems to make it
impossible to bisect to a specific commit.
What I do know is that the problem was originally introduced by
49183b2818de ("drm/i915: Only enable the plane after setting the fb
base (pre-ILK)"). It was subsequently fixed by 982b2035d9d7 ("Revert
"drm/i915: Only enable the plane after setting the fb base (pre-ILK)"").
The problem was reintroduced by 98b98d316349 ("Merge branch 'drm-core-next'
of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6").
Unfortunately, I cannot be more specific than that because it appears
that the entire drm side of that merge consists of 'bad' commits and git
bisect gets very confused.
Let me know if you need any more info,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
[PATCH] drm/radeon/kms: fix mac g5 quirk
Apple uses the same subsystem pci ids for lots of
hardware much of which is wired up differently. In
this case, the G5 imac and the G5 tower.
Only apply the quirk configuration to G5 towers.
Reported-by: Joachim Henke
Signed-off-by: Alex Deucher
Cc: Joachim Henke
Cc: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_combios.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c
index 5b991f7..19b10cf 100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -1548,9 +1548,8 @@ bool radeon_get_legacy_connector_info_from_table(struct
drm_device *dev)
(rdev->pdev->subsystem_device == 0x4a48)) {
/* Mac X800 */
rdev->mode_info.connector_table = CT_MAC_X800;
- } else if ((rdev->pdev->device == 0x4150) &&
- (rdev->pdev->subsystem_vendor == 0x1002) &&
- (rdev->pdev->subsystem_device == 0x4150)) {
+ } else if (of_machine_is_compatible("PowerMac7,2") ||
+ of_machine_is_compatible("PowerMac7,3")) {
/* Mac G5 9600 */
rdev->mode_info.connector_table = CT_MAC_G5_9600;
} else
--
1.7.1.1
[PATCH] savage: remove unecessary if statement
* Greg Dietsche : > the code always returns ret regardless, so if(ret) check is unecessary. /unecessary/unnecessary/ > > Signed-off-by: Greg Dietsche Reviewed-by: Nicolas Kaiser Best regards, Nicolas Kaiser > --- > drivers/gpu/drm/savage/savage_bci.c |3 --- > 1 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/savage/savage_bci.c > b/drivers/gpu/drm/savage/savage_bci.c > index bf5f83e..cb1ee4e 100644 > --- a/drivers/gpu/drm/savage/savage_bci.c > +++ b/drivers/gpu/drm/savage/savage_bci.c > @@ -647,9 +647,6 @@ int savage_driver_firstopen(struct drm_device *dev) > ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE, >_DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING, >_priv->aperture); > - if (ret) > - return ret; > - > return ret; > } >
[Bug 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors
https://bugs.freedesktop.org/show_bug.cgi?id=29226 Michal Suchanek changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors
https://bugs.freedesktop.org/show_bug.cgi?id=29226 --- Comment #14 from Michal Suchanek 2011-06-06 07:46:16 PDT --- Yes, this has been fixed in 7.11. A piglit test for this would be nice because it was a longstanding issue for which I did not find any test neither in piglit nor in mesa-demos. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] nouveau: ACPI support is dependent on X86
The ACPI support code probably wasn't very useful on ia64, and now depends on mxm-wmi which is definitely x86-only. Compile-tested on ia64 and i386. Signed-off-by: Ben Hutchings --- drivers/gpu/drm/nouveau/Kconfig |4 ++-- drivers/gpu/drm/nouveau/Makefile |2 ++ drivers/gpu/drm/nouveau/nouveau_drv.h |2 +- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig index ca16399..5a85697 100644 --- a/drivers/gpu/drm/nouveau/Kconfig +++ b/drivers/gpu/drm/nouveau/Kconfig @@ -11,8 +11,8 @@ config DRM_NOUVEAU select FRAMEBUFFER_CONSOLE if !EXPERT select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && VIDEO_OUTPUT_CONTROL && INPUT - select ACPI_WMI if ACPI - select MXM_WMI if ACPI + select ACPI_WMI if ACPI && X86 + select MXM_WMI if ACPI && X86 help Choose this option for open-source nVidia support. diff --git a/drivers/gpu/drm/nouveau/Makefile b/drivers/gpu/drm/nouveau/Makefile index 0583677..797b808 100644 --- a/drivers/gpu/drm/nouveau/Makefile +++ b/drivers/gpu/drm/nouveau/Makefile @@ -37,6 +37,8 @@ nouveau-y := nouveau_drv.o nouveau_state.o nouveau_channel.o nouveau_mem.o \ nouveau-$(CONFIG_DRM_NOUVEAU_DEBUG) += nouveau_debugfs.o nouveau-$(CONFIG_COMPAT) += nouveau_ioc32.o nouveau-$(CONFIG_DRM_NOUVEAU_BACKLIGHT) += nouveau_backlight.o +ifdef CONFIG_X86 nouveau-$(CONFIG_ACPI) += nouveau_acpi.o +endif obj-$(CONFIG_DRM_NOUVEAU)+= nouveau.o diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h b/drivers/gpu/drm/nouveau/nouveau_drv.h index 9c56331..9ea5a17 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h @@ -968,7 +968,7 @@ extern int nouveau_dma_wait(struct nouveau_channel *, int slots, int size); /* nouveau_acpi.c */ #define ROM_BIOS_PAGE 4096 -#if defined(CONFIG_ACPI) +#if defined(CONFIG_ACPI) && defined(CONFIG_X86) void nouveau_register_dsm_handler(void); void nouveau_unregister_dsm_handler(void); int nouveau_acpi_get_bios_chunk(uint8_t *bios, int offset, int len); -- 1.7.5.3
Regression: Borked display on second output with Intel G45 in 3.0-rc2
After upgrading to 3.0-rc2, my second display is no longer working correctly on a desktop with an Intel G45 graphics chip. The system has two displays, one connected by HDMI and the other by VGA. Both displays work fine in the console; the troubles begin after starting X. It *looks* as if one of the displays is still scanning out from the old framebuffer: what I see on the VGA monitor after starting X is a black screen with a console cursor at the top -- this is just like an empty VT except that the cursor is not blinking. If I switch to VT 1 and then back to X, the display contains all the bootup text that was on VT 1. In any case, the mouse cursor works properly on the display. There are no unusual messages in dmesg or the Xorg log in any case. If I fiddle around with the xrandr tool (e.g. do an xrandr --output VGA1 --same-as HDMI1 xrandr --output VGA1 --right-of VGA1) , it's possible to get both displays showing the right thing. But then if I switch back to the console, I end up with one display showing the console text and the other is still showing my X session! (In this instance, the VGA was working and the HDMI was showing the wrong thing). This is a regression from 2.6.39, but that's not the whole story: this problem appears to have been introduced very briefly late in the 2.6.39 -rc cycle and subsequently fixed on mainline. It then reappeared during the 3.0 merge window. Unfortunately, this fact seems to make it impossible to bisect to a specific commit. What I do know is that the problem was originally introduced by 49183b2818de (drm/i915: Only enable the plane after setting the fb base (pre-ILK)). It was subsequently fixed by 982b2035d9d7 (Revert drm/i915: Only enable the plane after setting the fb base (pre-ILK)). The problem was reintroduced by 98b98d316349 (Merge branch 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6). Unfortunately, I cannot be more specific than that because it appears that the entire drm side of that merge consists of 'bad' commits and git bisect gets very confused. Let me know if you need any more info, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
On 2011-06-06 19:20 +0200, Melchior FRANZ wrote: * Nick Bowler -- Monday 06 June 2011: After upgrading to 3.0-rc2, my second display is no longer working correctly on a desktop with an Intel G45 graphics chip. [...] What I do know is that the problem was originally introduced by 49183b2818de (drm/i915: Only enable the plane after setting the fb base (pre-ILK)). It was subsequently fixed by 982b2035d9d7 (Revert drm/i915: Only enable the plane after setting the fb base (pre-ILK)). The problem was reintroduced by 98b98d316349 (Merge branch 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6). That's apparently the bug that I've submitted a patch for on 2011/5/31: https://lkml.org/lkml/2011/5/31/393 I assume/hope it's still in someone's queue. Yup, that fixes it right up, thanks. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit
Since printk_ratelimit() shouldn't be used anymore (see comment in include/linux/printk.h), replace it with printk_ratelimited. Signed-off-by: Christian Dietrich christian.dietr...@informatik.uni-erlangen.de --- drivers/gpu/drm/drm_ioc32.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c index d61d185..4a058c7 100644 --- a/drivers/gpu/drm/drm_ioc32.c +++ b/drivers/gpu/drm/drm_ioc32.c @@ -28,6 +28,7 @@ * IN THE SOFTWARE. */ #include linux/compat.h +#include linux/ratelimit.h #include drmP.h #include drm_core.h @@ -253,10 +254,10 @@ static int compat_drm_addmap(struct file *file, unsigned int cmd, return -EFAULT; m32.handle = (unsigned long)handle; - if (m32.handle != (unsigned long)handle printk_ratelimit()) - printk(KERN_ERR compat_drm_addmap truncated handle - %p for type %d offset %x\n, - handle, m32.type, m32.offset); + if (m32.handle != (unsigned long)handle) + printk_ratelimited(KERN_ERR compat_drm_addmap truncated handle + %p for type %d offset %x\n, + handle, m32.type, m32.offset); if (copy_to_user(argp, m32, sizeof(m32))) return -EFAULT; -- 1.7.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] Use printk_ratelimited instead of printk_ratelimit
Hi, since printk_ratelimit() shouldn't be used anymore, I replaced it at several points, where it was possible with printk_ratelimited(FMT,...). This shouldn't change the behaviour in most cases, except that the printk will use an local ratelimit instead of an global one shared with all other printk_ratelimit calls. I just must made patches for a few places where it is used. If you think that it is worth converting all printk_ratelimits, i will send more patches. The changes where done against v3.0-rc1-106-g4f1ba49. greetz chris Christian Dietrich (8): powerpc/rtas-rtc: remove sideeffects of printk_ratelimit drivers/octeon: use printk_ratelimited instead of printk_ratelimit scsi/sg: use printk_ratelimited instead of printk_ratelimit md/raid: use printk_ratelimited instead of printk_ratelimit drivers/char/rtc: use printk_ratelimited instead of printk_ratelimit drivers/gpu/drm: use printk_ratelimited instead of printk_ratelimit arch/powerpc: use printk_ratelimited instead of printk_ratelimit arch/x86: use printk_ratelimited instead of printk_ratelimit arch/powerpc/kernel/rtas-rtc.c | 29 +-- arch/powerpc/kernel/signal_32.c | 57 +-- arch/powerpc/kernel/signal_64.c | 17 + arch/powerpc/kernel/traps.c | 22 +-- arch/powerpc/mm/fault.c | 10 +++--- arch/powerpc/sysdev/mpic.c | 11 +++--- arch/x86/kernel/hpet.c |6 ++-- arch/x86/kernel/irq.c |9 ++--- arch/x86/kvm/i8259.c|7 ++-- arch/x86/lguest/boot.c |6 ++-- drivers/char/rtc.c |7 ++-- drivers/gpu/drm/drm_ioc32.c |9 +++-- drivers/md/raid1.c | 22 ++- drivers/md/raid10.c | 22 ++- drivers/md/raid5.c | 39 ++--- drivers/scsi/sg.c | 18 + drivers/staging/octeon/ethernet-mdio.c | 27 +++--- drivers/staging/octeon/ethernet-rgmii.c | 33 +- drivers/staging/octeon/ethernet-rx.c| 24 +++-- drivers/staging/octeon/ethernet-sgmii.c | 14 --- drivers/staging/octeon/ethernet-tx.c| 11 +++--- drivers/staging/octeon/ethernet-util.h |4 -- drivers/staging/octeon/ethernet-xaui.c | 22 ++- 23 files changed, 221 insertions(+), 205 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] savage: remove unecessary if statement
the code always returns ret regardless, so if(ret) check is unecessary. Signed-off-by: Greg Dietsche gregory.diets...@cuw.edu --- drivers/gpu/drm/savage/savage_bci.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/savage/savage_bci.c b/drivers/gpu/drm/savage/savage_bci.c index bf5f83e..cb1ee4e 100644 --- a/drivers/gpu/drm/savage/savage_bci.c +++ b/drivers/gpu/drm/savage/savage_bci.c @@ -647,9 +647,6 @@ int savage_driver_firstopen(struct drm_device *dev) ret = drm_addmap(dev, aperture_base, SAVAGE_APERTURE_SIZE, _DRM_FRAME_BUFFER, _DRM_WRITE_COMBINING, dev_priv-aperture); - if (ret) - return ret; - return ret; } -- 1.7.2.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression: Borked display on second output with Intel G45 in 3.0-rc2
On Mon, 6 Jun 2011 19:20:06 +0200, Melchior FRANZ melchior.fr...@gmail.com wrote: That's apparently the bug that I've submitted a patch for on 2011/5/31: https://lkml.org/lkml/2011/5/31/393 I assume/hope it's still in someone's queue. Yeah, we shouldn't need to call intel_enable_plane from i9xx_crtc_mode_set as it is called immediately afterwards from i9xx_crtc_enable. In any case, there's a bogus call in ironlake_crtc_mode_set which clearly belongs in i9xx_crtc_mode_set: diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 81a9059..aa43e7b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4687,6 +4687,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); + intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); @@ -5217,8 +5218,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc, I915_WRITE(DSPCNTR(plane), dspcntr); POSTING_READ(DSPCNTR(plane)); - if (!HAS_PCH_SPLIT(dev)) - intel_enable_plane(dev_priv, plane, pipe); ret = intel_pipe_set_base(crtc, x, y, old_fb); We need to figure out why this call (in i9xx_crtc_mode_set) is required, but that will require finding hardware that reproduces the bug and fixing it there. -- keith.pack...@intel.com pgp0Opa75FnW7.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #9 from Pierre-Eric Pelloux-Prayer pell...@gmail.com 2011-06-06 13:28:16 PDT --- Created an attachment (id=47621) View: https://bugs.freedesktop.org/attachment.cgi?id=47621 Review: https://bugs.freedesktop.org/review?bug=37028attachment=47621 proposed patch Could you please try this patch ? It should fix the issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/drm/i915 maintenance process
On Sat, 04 Jun 2011 23:05:23 -0700 Keith Packard kei...@keithp.com wrote: 1) drm-intel-next This contains work destined for the 'next' release, it may include new functionality and performance enhancements. It may also cause regressions on some hardware. The tip of this tree will be sent to Dave Airlie for inclusion in the kernel during the next merge window. I've already sent all of what is on this branch to him for 3.0 This tree should be tested during the development process to try and catch bugs and regressions before they are merged. The most critical time for testing this is just *before* the release of the current RC kernel version as that is when it should have most of the code planned for the *next* release. 2) drm-intel-fixes This contains bug fixes after the merge window has closed. I will fast-forwarded to each RC when possible so that we test the fully integrated kernel for regressions. This tree should be tested during the stabilization process after RC1 comes out as patches are applied. Can you keep drm-intel-next fairly up to date with respect to the fixes branch? I.e. keep it a superset of drm-intel-fixes for the most part? In PCI-land, this means re-basing my -next tree periodically before the merge window opens (though not right before the merge window unless something unexpected happens, like a patch needing to be dropped; in that case I'll delay the merge window push a bit to allow for more testing). Downstream PCI developers requested this since it makes feature development much easier (you get all the bug fixes destined for Linus while working on a new feature for the next window), and as a downstream gfx developer I'd like to see this on the Intel side as well, unless other developers have big objections... Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38010] New: DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 Summary: DVI output not working with radeon on RV610 Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: darkbas...@gmail.com Created an attachment (id=47622) -- (https://bugs.freedesktop.org/attachment.cgi?id=47622) dmesg Hi, I have an RV610 card attached to an LG 22LH2000. The LG 22LH2000 has a 1366x768 native resolution and does have VGA and HDMI but not DVI. The Radeon HD2400 does have VGA and DVI but not HDMI, so I'm using a DVI-HDMI converter. When I use the VGA output everything works fine, but I don't get a 1:1 pixel mapping because I have to set a 1360x768 or 1368x768 resolution and the monitor is not smart enough when using vga. Instead when I attach the monitor to my laptop's Intel GMA45 HDMI output I can get a 1:1 pixel mapping even using a 1360x768 resolution. Unfortunately when using the HD2400 DVI output the monitor does not show anything, at least after loading the radeon module. In fact when loading the bios or starting grub the DVI output works flawlessly. nomodeset does not help. I even tried setting another resolution with xrandr (it automatically set 1920x1080i, but I tried 1360x768, 1280x800, 1024x768 and 800x600 and it still does not work). Distro is Debian Unstable amd64 with kernel 2.6.39 and xorg-edgers ppa. It's the only monitor I will be able to use for a couple of months, it's critical for me to get it working. Thank you -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38010] DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 --- Comment #1 from Alex Deucher ag...@yahoo.com 2011-06-06 14:13:06 PDT --- Does booting with radeon.audio=0 on the kernel command line in grub help? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38010] DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 --- Comment #2 from darkbasic darkbas...@gmail.com 2011-06-06 14:13:48 PDT --- Created an attachment (id=47623) -- (https://bugs.freedesktop.org/attachment.cgi?id=47623) Xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38010] DVI output not working with radeon on RV610
https://bugs.freedesktop.org/show_bug.cgi?id=38010 --- Comment #3 from darkbasic darkbas...@gmail.com 2011-06-06 14:18:41 PDT --- Does booting with radeon.audio=0 on the kernel command line in grub help? OMG you had been faster than light, and it worked! Consider this card does not even have an HDMI output! Thank you very much P.S. Should I close this? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: disable hdmi audio by default
The current RE'd code causes blank screens and display problems on a lot of systems. So disable it by default for now. It can still be enabled by setting the audio parameter to 1. E.g.: radeon.audio=1 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38010 https://bugs.freedesktop.org/show_bug.cgi?id=27731 https://bugs.freedesktop.org/show_bug.cgi?id=35970 https://bugs.freedesktop.org/show_bug.cgi?id=26195 and many other reported problems. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/radeon_drv.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 1d33060..73dfbe8 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -113,7 +113,7 @@ int radeon_benchmarking = 0; int radeon_testing = 0; int radeon_connector_table = 0; int radeon_tv = 1; -int radeon_audio = 1; +int radeon_audio = 0; int radeon_disp_priority = 0; int radeon_hw_i2c = 0; int radeon_pcie_gen2 = 0; @@ -151,7 +151,7 @@ module_param_named(connector_table, radeon_connector_table, int, 0444); MODULE_PARM_DESC(tv, TV enable (0 = disable)); module_param_named(tv, radeon_tv, int, 0444); -MODULE_PARM_DESC(audio, Audio enable (0 = disable)); +MODULE_PARM_DESC(audio, Audio enable (1 = enable)); module_param_named(audio, radeon_audio, int, 0444); MODULE_PARM_DESC(disp_priority, Display Priority (0 = auto, 1 = normal, 2 = high)); -- 1.7.1.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Flat address space with gGTT / ppGTT
Hello all, I saw at some point that per-process GTT (ppGTT) may be (or is already) implemented to handle paging. Right now, I am investigating some flat space addressing (ab)using surface states. The idea is to create a surface state (raw buffer only, this is GPGPU stuff) as big enough to cover the entire address space such that I will only manipulate offsets as pointers in this surface instead of dealing with both offsets and surface IDs (in other words, segmented address space). My concern is relative to the way bo buffers are mapped. Basically, I must be sure that _all_ of them are either mapped using ppGTT or GTT. Otherwise, this will also bring another form of segmentation. If ppGTT is implemented or will be implemented, will there be anyway to know how a bo is mapped? Cheers, Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/drm/i915 maintenance process
On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Can you keep drm-intel-next fairly up to date with respect to the fixes branch? I.e. keep it a superset of drm-intel-fixes for the most part? Yes, I wanted to do that now, but -fixes is not a fast-forward from -next and I thought I shouldn't be doing rebases. In PCI-land, this means re-basing my -next tree periodically before the merge window opens (though not right before the merge window unless something unexpected happens, like a patch needing to be dropped; in that case I'll delay the merge window push a bit to allow for more testing). If a rebase around -RC1 is reasonable, then I'll do that now and move changes over to that. -- keith.pack...@intel.com pgpy4bzryrDsu.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/drm/i915 maintenance process
On Mon, 06 Jun 2011 16:24:46 -0700 Keith Packard kei...@keithp.com wrote: On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Can you keep drm-intel-next fairly up to date with respect to the fixes branch? I.e. keep it a superset of drm-intel-fixes for the most part? Yes, I wanted to do that now, but -fixes is not a fast-forward from -next and I thought I shouldn't be doing rebases. You shouldn't if your downstream is using git trees and you're pulling from them, but it depends on your downstream. In my particular case, I'm ok with rebases if it means I get fixes. :) -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
