[git pull] drm-next
Hi Linus, Please pull the 'drm-next' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next This branch has a merge in it, due to conflicts with the Intel drm tree you already pulled. I've asked Eric to not send you direct pulls, he mentioned you said he should, but it really screws over my tree. I don't mind direct pulls outside the merge window as it usually smaller bug fixes, but during the merge window the chances of it getting messy like this tree has become just increase. So highlights of this pull: 1. ATI R6/700 + RS600 DRM support added. 2. PowerPC 440 fixes for having resources 32-bit on 32-bit CPU 3. radeon on sparc fixes, davem can play quake3 now. Dave. drivers/gpu/drm/ati_pcigart.c | 40 +- drivers/gpu/drm/drm_bufs.c | 122 +- drivers/gpu/drm/drm_context.c |4 +- drivers/gpu/drm/drm_drv.c | 88 +- drivers/gpu/drm/drm_edid.c | 183 +- drivers/gpu/drm/drm_fops.c |1 + drivers/gpu/drm/drm_gem.c |2 +- drivers/gpu/drm/drm_info.c |6 +- drivers/gpu/drm/drm_ioc32.c |4 + drivers/gpu/drm/drm_memory.c|6 +- drivers/gpu/drm/drm_proc.c |1 - drivers/gpu/drm/drm_stub.c | 93 +- drivers/gpu/drm/drm_sysfs.c | 37 +- drivers/gpu/drm/drm_vm.c| 32 +- drivers/gpu/drm/i810/i810_drv.h |4 +- drivers/gpu/drm/i830/i830_drv.h |4 +- drivers/gpu/drm/i915/i915_dma.c |2 +- drivers/gpu/drm/i915/i915_drv.c | 38 + drivers/gpu/drm/i915/i915_gem.c |7 +- drivers/gpu/drm/mga/mga_dma.c | 17 +- drivers/gpu/drm/mga/mga_drv.h |8 +- drivers/gpu/drm/r128/r128_cce.c |7 +- drivers/gpu/drm/radeon/Makefile |2 +- drivers/gpu/drm/radeon/r300_cmdbuf.c| 11 +- drivers/gpu/drm/radeon/r300_reg.h |5 + drivers/gpu/drm/radeon/r600_cp.c| 2253 +++ drivers/gpu/drm/radeon/r600_microcode.h |23297 +++ drivers/gpu/drm/radeon/radeon_cp.c | 522 +- drivers/gpu/drm/radeon/radeon_drv.c | 22 +- drivers/gpu/drm/radeon/radeon_drv.h | 635 +- drivers/gpu/drm/radeon/radeon_irq.c | 14 +- drivers/gpu/drm/radeon/radeon_state.c | 51 +- drivers/gpu/drm/savage/savage_bci.c |8 +- drivers/gpu/drm/via/via_drv.c |6 - include/drm/drmP.h | 68 +- include/drm/drm_crtc.h |6 +- include/drm/drm_os_linux.h | 19 + include/drm/drm_pciids.h| 113 + include/drm/radeon_drm.h|5 +- 39 files changed, 27309 insertions(+), 434 deletions(-) create mode 100644 drivers/gpu/drm/radeon/r600_cp.c create mode 100644 drivers/gpu/drm/radeon/r600_microcode.h commit f23c20c83d523e5f8cda1f8f7ed52fe6afffbe29 Author: Ma Ling ling...@intel.com Date: Thu Mar 26 19:26:23 2009 +0800 drm: detect hdmi monitor by hdmi identifier (v3) Sometime we need to communicate with HDMI monitor by sending audio or video info frame, so we have to know monitor type. However if user utilize HDMI-DVI adapter to connect DVI monitor, hardware detection will incorrectly show the monitor is HDMI. HDMI spec tell us that any device containing IEEE registration Identifier will be treated as HDMI device. The patch intends to detect HDMI monitor by this rule. Signed-off-by: Ma Ling ling...@intel.com Signed-off-by: Dave Airlie airl...@redhat.com commit dba5ed0cd12d8db5c0d2e1c869c2a50c5bcf6743 Author: Dan Carpenter erro...@gmail.com Date: Fri Mar 27 13:34:28 2009 +0300 drm: drm_fops.c unlock missing on error path drm_open_helper() from drm_fops.c had a missing mutex_unlock in a error path. This was caught by smatch (http://repo.or.cz/w/smatch.git/). Compile tested. Signed-off-by: Dan Carpenter erro...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com commit c972d750e4fa3bfee6e7d3635729bf8c9cbb8f0a Author: Richard Kennedy rich...@rsk.demon.co.uk Date: Wed Mar 18 17:26:44 2009 + drm: reorder struct drm_ioctl_desc to save space on 64 bit builds shrinks drm_ioctl_desc from 24 bytes to 16 bytes by reordering members to remove padding. updates DRM_IOCTL_DEF macro to initialise structure members by name to handle the structure reorder. The applied patch reduces data used in drm.ko from 10440 to 9032 Signed-off-by: Richard Kennedy rich...@rsk.demon.co.uk Signed-off-by: Dave Airlie airl...@redhat.com commit 40fc6eab599d0087a75fc77eaaf04d769b667f6d Author: Alex Deucher alexdeuc...@gmail.com Date: Thu Mar 19 20:44:22 2009 -0400 radeon: add some new pci ids This adds some new RS780 pci ids Signed-off-by: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Dave Airlie airl...@redhat.com
Re: [git pull] drm-next
On Sun, 29 Mar 2009, Dave Airlie wrote: This branch has a merge in it, due to conflicts with the Intel drm tree you already pulled. I've asked Eric to not send you direct pulls, he mentioned you said he should, but it really screws over my tree. I don't mind direct pulls outside the merge window as it usually smaller bug fixes, but during the merge window the chances of it getting messy like this tree has become just increase. Qutie frankly, I don't like how you always rebased patches, so I'd _much_ rather see direct pulls than the alternative. And I can handle most merge issues, and will ask submaintainers to merge for me only if it gets really complicated. If this encourages people to keep DRI drivers more modular and independent, that's all good. Linus -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm-next
This branch has a merge in it, due to conflicts with the Intel drm tree you already pulled. I've asked Eric to not send you direct pulls, he mentioned you said he should, but it really screws over my tree. I don't mind direct pulls outside the merge window as it usually smaller bug fixes, but during the merge window the chances of it getting messy like this tree has become just increase. Qutie frankly, I don't like how you always rebased patches, so I'd _much_ rather see direct pulls than the alternative. And I can handle most merge issues, and will ask submaintainers to merge for me only if it gets really complicated. If this encourages people to keep DRI drivers more modular and independent, that's all good. That's fine you only requested I stop rebasing Eric's tree since the last merge window, I haven't had to pull it since then to send to you. This merge there was 3 conflicts, I think they were mostly trivial, however there was also a warning fix in i915 for a return type not checked that no-one else picked up on. I'm still awaiting Documentation/linus-rules-for-git-trees.txt. I'm sure every other maintainer who is just guessing what the rules are would appreciate it as well. We don't all have the time of Ingo to do a branch per patch with a scary octopus merge every few weeks. My plans from now on are just to send you non-linear trees, whenever I merge a patch into my next tree thats when it stays in there, I'll pull Eric's tree directly into my tree and then I'll send the results, I thought we cared about a clean merge history but as I said without some document in the kernel tree I've up until now had no real idea what you wanted. Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm-next
On Sun, 29 Mar 2009, Dave Airlie wrote: My plans from now on are just to send you non-linear trees, whenever I merge a patch into my next tree thats when it stays in there, I'll pull Eric's tree directly into my tree and then I'll send the results, I thought we cared about a clean merge history but as I said without some document in the kernel tree I've up until now had no real idea what you wanted. I want clean history, but that really means (a) clean and (b) history. People can (and probably should) rebase their _private_ trees (their own work). That's a _cleanup_. But never other peoples code. That's a destroy history So the history part is fairly easy. There's only one major rule, and one minor clarification: - You must never EVER destroy other peoples history. You must not rebase commits other people did. Basically, if it doesn't have your sign-off on it, it's off limits: you can't rebase it, because it's not yours. Notice that this really is about other peoples _history_, not about other peoples _code_. If they sent stuff to you as an emailed patch, and you applied it with git am -s, then it's their code, but it's _your_ history. So you can go wild on the git rebase thing on it, even though you didn't write the code, as long as the commit itself is your private one. - Minor clarification to the rule: once you've published your history in some public site, other people may be using it, and so now it's clearly not your _private_ history any more. So the minor clarification really is that it's not just about your commit, it's also about it being private to your tree, and you haven't pushed it out and announced it yet. That's fairly straightforward, no? Now the clean part is a bit more subtle, although the first rules are pretty obvious and easy: - Keep your own history readable Some people do this by just working things out in their head first, and not making mistakes. but that's very rare, and for the rest of us, we use git rebase etc while we work on our problems. So git rebase is not wrong. But it's right only if it's YOUR VERY OWN PRIVATE git tree. - Don't expose your crap. This means: if you're still in the git rebase phase, you don't push it out. If it's not ready, you send patches around, or use private git trees (just as a patch series replacement) that you don't tell the public at large about. It may also be worth noting that excessive git rebase will not make things any cleaner: if you do too many rebases, it will just mean that all your old pre-rebase testing is now of dubious value. So by all means rebase your own work, but use _some_ judgement in it. NOTE! The combination of the above rules (clean your own stuff vs don't clean other peoples stuff) have a secondary indirect effect. And this is where it starts getting subtle: since you most not rebase other peoples work, that means that you must never pull into a branch that isn't already in good shape. Because after you've done a merge, you can no longer rebase you commits. Notice? Doing a git pull ends up being a synchronization point. But it's all pretty easy, if you follow these two rules about pulling: - Don't merge upstream code at random points. You should _never_ pull my tree at random points (this was my biggest issue with early git users - many developers would just pull my current random tree-of-the-day into their development trees). It makes your tree just a random mess of random development. Don't do it! And, in fact, preferably you don't pull my tree at ALL, since nothing in my tree should be relevant to the development work _you_ do. Sometimes you have to (in order to solve some particularly nasty dependency issue), but it should be a very rare and special thing, and you should think very hard about it. But if you want to sync up with major releases, do a git pull linus-repo v2.6.29 or similar to synchronize with that kind of _non_random_ point. That all makes sense. A Merge v2.6.29 into devel branch makes complete sense as a merge message, no? That's not a problem. But if I see a lot of Merge branch 'linus' in your logs, I'm not going to pull from you, because your tree has obviously had random crap in it that shouldn't be there. You also lose a lot of testability, since now all your tests are going to be about all my random code. - Don't merge _downstream_ code at random points either. Here the random points comment is a dual thing. You should not mege random points as far as downstream is concerned (they should tell you what to merge, and why), but also not random points as far as your tree is concerned. Simple version: Don't merge unrelated downstream stuff into your own topic branches. Slightly more complex version: Always have a _reason_ for merging downstream stuff. That
[Bug 20935] New: Perfomance regresion in r300_dri version 7.3 (7. 2 is twice faster)
http://bugs.freedesktop.org/show_bug.cgi?id=20935 Summary: Perfomance regresion in r300_dri version 7.3 (7.2 is twice faster) Product: Mesa Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: low Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: lukas.ka...@centrum.cz QAContact: lukas.ka...@centrum.cz Hi, version 7.3 of Mesa (MesaLib + MesaGlut) is twice slower that version 7.2 on my system! (I mean half fps in GlxGears, TuxRacer and other games.) I compile both version with the same parameters OPT_FLAGS = -O3 -g -fomit-frame-pointer -pipe -march=k8 -funroll-loops \ -mfpmath=sse -mmmx -msse -msse2 -m3dnow -mcx16 My graphic card is ATI Radeon Express 1100 (chipset RS485). -- Configure bugmail: http://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.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm-next
I want clean history, but that really means (a) clean and (b) history. People can (and probably should) rebase their _private_ trees (their own work). That's a _cleanup_. But never other peoples code. That's a destroy history So the history part is fairly easy. There's only one major rule, and one minor clarification: - You must never EVER destroy other peoples history. You must not rebase commits other people did. Basically, if it doesn't have your sign-off on it, it's off limits: you can't rebase it, because it's not yours. Notice that this really is about other peoples _history_, not about other peoples _code_. If they sent stuff to you as an emailed patch, and you applied it with git am -s, then it's their code, but it's _your_ history. So you can go wild on the git rebase thing on it, even though you didn't write the code, as long as the commit itself is your private one. - Minor clarification to the rule: once you've published your history in some public site, other people may be using it, and so now it's clearly not your _private_ history any more. So the minor clarification really is that it's not just about your commit, it's also about it being private to your tree, and you haven't pushed it out and announced it yet. That's fairly straightforward, no? Now the clean part is a bit more subtle, although the first rules are pretty obvious and easy: - Keep your own history readable Some people do this by just working things out in their head first, and not making mistakes. but that's very rare, and for the rest of us, we use git rebase etc while we work on our problems. So git rebase is not wrong. But it's right only if it's YOUR VERY OWN PRIVATE git tree. - Don't expose your crap. This means: if you're still in the git rebase phase, you don't push it out. If it's not ready, you send patches around, or use private git trees (just as a patch series replacement) that you don't tell the public at large about. It may also be worth noting that excessive git rebase will not make things any cleaner: if you do too many rebases, it will just mean that all your old pre-rebase testing is now of dubious value. So by all means rebase your own work, but use _some_ judgement in it. NOTE! The combination of the above rules (clean your own stuff vs don't clean other peoples stuff) have a secondary indirect effect. And this is where it starts getting subtle: since you most not rebase other peoples work, that means that you must never pull into a branch that isn't already in good shape. Because after you've done a merge, you can no longer rebase you commits. Notice? Doing a git pull ends up being a synchronization point. But it's all pretty easy, if you follow these two rules about pulling: - Don't merge upstream code at random points. You should _never_ pull my tree at random points (this was my biggest issue with early git users - many developers would just pull my current random tree-of-the-day into their development trees). It makes your tree just a random mess of random development. Don't do it! And, in fact, preferably you don't pull my tree at ALL, since nothing in my tree should be relevant to the development work _you_ do. Sometimes you have to (in order to solve some particularly nasty dependency issue), but it should be a very rare and special thing, and you should think very hard about it. The only case I can think off here, is when I send a tree of bug fixes to your tree during -rc and I want to make sure the drm-next tree is tested with those fixes applied to it. Is that an acceptable time to pull in your tree? Normally I rebase the drm-next tree on top of the drm-fixes tree so I know the testing is done with all known fixes in it, however it seems I should merge your tree at that point instead into drm-next. Thanks for all this, its quite clear now, I should clean this mail up and put it into the kernel documentation. Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm-next
On Mon, 30 Mar 2009, Dave Airlie wrote: - Don't merge upstream code at random points. You should _never_ pull my tree at random points (this was my biggest issue with early git users - many developers would just pull my current random tree-of-the-day into their development trees). It makes your tree just a random mess of random development. Don't do it! And, in fact, preferably you don't pull my tree at ALL, since nothing in my tree should be relevant to the development work _you_ do. Sometimes you have to (in order to solve some particularly nasty dependency issue), but it should be a very rare and special thing, and you should think very hard about it. The only case I can think off here, is when I send a tree of bug fixes to your tree during -rc and I want to make sure the drm-next tree is tested with those fixes applied to it. I would actually prefer that in this case - especially if things merge cleanly and automatically - you still aim to not merge with me in your development branch. But the test teh merged state is obviously a real issue, and it happens at other times than just during the -rc time. In fact, it happens most commonly long before you even want to send me any pull requests, simply because the merge window hasn't even opened yet. So what's the solution? You want to merge for testing, yet I don't want to see random merges of the day in the development tree when I pull? I suspect you can already see the solution coming when I put it that way: the best way is to simply create a test-branch, and do the merge there, and use _that_ branch for testing and for (for example) sending off to the linux-next repository which will combine it with yet other test branches. But note: none of these rules should be absolutely black-and-white. Nothing in life ever is. Sometimes merging with my tree is simply the best option. If it's not your normal mode of operation, but an option in your toolbox that you end up using when everything else is just too painful, go ahead. Git does allow people to do many different things, and solve problems different ways. I just want all the regular workflows to be good practice, but then if you have to occasionally break the rules to solve some odd problem, go ahead and break the rules (and tell people why you did it that way this time). Thanks for all this, its quite clear now, I should clean this mail up and put it into the kernel documentation. Hey, good idea. We have some of that, but if you found the email useful, do feel free to turn it into real documentation. Linus -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] RS780: load the right microcode
http://www.botchco.com/alex/xorg/r6xx_drm/0001-RS780-load-the-right-microcode.patch From 4299cc7ee205006851a7a791602efa8512613f16 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Sun, 29 Mar 2009 20:40:34 -0400 Subject: [PATCH] RS780: load the right microcode Copy/paste error. The RV670 microcode should work ok, so it's not a show stopper. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/r600_cp.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c index dee3840..d4e66da 100644 --- a/drivers/gpu/drm/radeon/r600_cp.c +++ b/drivers/gpu/drm/radeon/r600_cp.c @@ -388,17 +388,17 @@ static void r600_cp_load_microcode(drm_radeon_private_t *dev_priv) DRM_INFO(Loading RS780 CP Microcode\n); for (i = 0; i PM4_UCODE_SIZE; i++) { RADEON_WRITE(R600_CP_ME_RAM_DATA, -RV670_cp_microcode[i][0]); +RS780_cp_microcode[i][0]); RADEON_WRITE(R600_CP_ME_RAM_DATA, -RV670_cp_microcode[i][1]); +RS780_cp_microcode[i][1]); RADEON_WRITE(R600_CP_ME_RAM_DATA, -RV670_cp_microcode[i][2]); +RS780_cp_microcode[i][2]); } RADEON_WRITE(R600_CP_PFP_UCODE_ADDR, 0); DRM_INFO(Loading RS780 PFP Microcode\n); for (i = 0; i PFP_UCODE_SIZE; i++) - RADEON_WRITE(R600_CP_PFP_UCODE_DATA, RV670_pfp_microcode[i]); + RADEON_WRITE(R600_CP_PFP_UCODE_DATA, RS780_pfp_microcode[i]); } RADEON_WRITE(R600_CP_PFP_UCODE_ADDR, 0); RADEON_WRITE(R600_CP_ME_RAM_WADDR, 0); -- 1.5.6.3 -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
macro/micro tiling scanout buffers on radeon
Does anyone remember why we've only done macro tiling on the radeon for the color buffer so far? I've been playing with tiling under KMS and I've added back macro tiling for the front/back buffers and it seems to run fine, however micro tiling the front buffer gives me corrupt pixmaps from X on it. I'm not sure if this is a limitation of the blitter (I'm setting the correct bits in the SRC/DST) but since we've never tried to microtile the front buffer before I thought someone might remember why. The chip can definitely scan it out properly, it just appears as if the blits get messed up. Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: macro/micro tiling scanout buffers on radeon
On Mon, Mar 30, 2009 at 12:42 PM, Dave Airlie airl...@gmail.com wrote: Does anyone remember why we've only done macro tiling on the radeon for the color buffer so far? /me discovers the reason ouch. So the 2D engine can't deal with a microtiled surface as a source, so short of using the 3D engine to do blits etc, microtiling isn't probably going to be useful for color buffers. For texture tiling I'm going to have to with keeping two copies as with this limitation we can't copy back from VRAM a micro-tiled texture with the blitter. Again we'd have to use the 3D engine to do it. Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enabling kms for i915 disables brightness control and xrandr
On Sun, 2009-03-29 at 14:07 +0100, Sitsofe Wheeler wrote: (CC'ing dri-devel, Eric Anholt and Jesse Barnes) On Sun, Mar 29, 2009 at 12:34:01PM +0200, Soeren Sonnenburg wrote: Dear all, I am not sure if this is just a user error/ too old userspace problem, [User stated that 2.6.3 intel driver is being used in another email] Just to not cause any (further?) confusion, I was using 2.6.1 when I wrote that email and after compiling/upgrading to 2.6.3 a number of problems vanished (like Xv works, screen resolution is correct, things are *a lot* faster with UXA). However, brightness still only works via setpci and xrandr only shows the 1024x600 modeline. but I recognized that when I enable kernel based modesetting on a intel 945 based samsung nc 10 netbook, I loose brightness control from within X and X resolutions are wrong (instead of 1024x600 it is 1024x1024) and xrandr does no longer have the all the modelines ranging from 1024x600 to 640x350... Trying to change resolutions / setting the brightness via xrandr results in error messages being printed. Furthermore, this same flag disables Xv support.. However, screen switches between terminal and X are quite fast now (without any flicker) and suspend and everything works stably. I recognized that I can set the brightness via setpci -s 00:02.1 F4.B=XX (XX ranging from 00 to FF) just fine... Soeren. -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: enabling kms for i915 disables brightness control and xrandr
(CC'ing dri-devel, Eric Anholt and Jesse Barnes) On Sun, Mar 29, 2009 at 12:34:01PM +0200, Soeren Sonnenburg wrote: Dear all, I am not sure if this is just a user error/ too old userspace problem, [User stated that 2.6.3 intel driver is being used in another email] but I recognized that when I enable kernel based modesetting on a intel 945 based samsung nc 10 netbook, I loose brightness control from within X and X resolutions are wrong (instead of 1024x600 it is 1024x1024) and xrandr does no longer have the all the modelines ranging from 1024x600 to 640x350... Trying to change resolutions / setting the brightness via xrandr results in error messages being printed. Furthermore, this same flag disables Xv support.. However, screen switches between terminal and X are quite fast now (without any flicker) and suspend and everything works stably. I recognized that I can set the brightness via setpci -s 00:02.1 F4.B=XX (XX ranging from 00 to FF) just fine... I am attaching the .config . Any ideas? Soeren -- Sitsofe | http://sucs.org/~sits/ -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel