Menu
▾
▴
dri-devel
|
From: Andy W. <aw...@ra...> - 2009-12-11 10:42:38
|
On Fri, 2009-12-11 at 01:34 -0800, David Miller wrote: > From: Alan Cox <al...@lx...> > Date: Fri, 11 Dec 2009 09:18:43 +0000 > > You also > > previously said you don't want to merge stuff when the authors don't want > > it merged. > However, one point remains is that we were told, by Dave Airlie, that > they didn't want this code merged because the one person being paid to > work on it "would be overwhelmed" if the code went upstream. > > I distinctly remember this being mentioned at the kernel summit. That reason for not merging seems to fall squarely in the "authors don't want it merged" category. Your point does highlight, though, that it is worth talking to the author directly to understand the obstacles, as Alan mentioned. Regards, Andy |
|
From: Dave A. <ai...@gm...> - 2009-12-11 10:21:08
|
On Fri, Dec 11, 2009 at 7:34 PM, David Miller <da...@da...> wrote: > From: Alan Cox <al...@lx...> > Date: Fri, 11 Dec 2009 09:18:43 +0000 > >> However the fundamental point stands. The only people who can sign it off >> are the people who wrote it. Those are the rules. Red Hat didn't write the >> code, Red Hat cannot sign it off however much you rant at them. You also >> previously said you don't want to merge stuff when the authors don't want >> it merged. > > I agree with a lot of what you say. > > However, one point remains is that we were told, by Dave Airlie, that > they didn't want this code merged because the one person being paid to > work on it "would be overwhelmed" if the code went upstream. > > I distinctly remember this being mentioned at the kernel summit. > > And you know what? That kind of excuse pisses me off too :-) Well the main thing was I wasn't mean to discuss possible legal issues and still don't have permission, you know as well as I do once lawyers are involved you have to keep out of things until they deal with them. but yes it is a side effect of upstreaming this code that other distros will start to place time demands on people who Red Hat employ but we were starting to see that anyways without upstreaming. It would be have been really nice if some of the distros would start to put their money behind what they want to ship instead of rhetoric[1]. Dave. [1] http://www.markshuttleworth.com/archives/95 |
|
From: <ty...@mi...> - 2009-12-11 13:04:23
|
On Fri, Dec 11, 2009 at 08:20:57PM +1000, Dave Airlie wrote: > > Well the main thing was I wasn't mean to discuss possible legal issues > and still don't have permission, you know as well as I do once lawyers are > involved you have to keep out of things until they deal with them. The thing which really surprises me is that if there are legally dubious issues, why on *earth* did Red Hat allow Fedora to ship said code? - Ted |
|
From: Alan C. <al...@lx...> - 2009-12-11 12:49:16
|
On Fri, 11 Dec 2009 07:45:41 -0500 ty...@mi... wrote: > On Fri, Dec 11, 2009 at 08:20:57PM +1000, Dave Airlie wrote: > > > > Well the main thing was I wasn't mean to discuss possible legal issues > > and still don't have permission, you know as well as I do once lawyers are > > involved you have to keep out of things until they deal with them. > > The thing which really surprises me is that if there are legally > dubious issues, why on *earth* did Red Hat allow Fedora to ship said > code? The thing which really surprises me is that if there are legal questions involved why on *earth* do people keep asking them on public mailing lists when they know the lawyers views/opinions/decisions will not be publishable there ? Ted, you of all people know that if you want to get an answer that isn't the way to get it. Alan |
|
From: Linus T. <tor...@li...> - 2009-12-11 00:33:53
|
On Thu, 10 Dec 2009, "C. Bergström" wrote: > > Thanks for the rather lengthly explanation, but in case you missed what people > are trying to say here.. > > With all due respect Linus.. > > "patches welcome" The problem is that I have never even heard a Red Hat or Fedora person actually acknoledge that yes, they should be trying to upstream it. Have Red Hat and Fedora just decided that "upstream first" simply doesn't matter any more? Because quite frankly, that was kind of the feeling I came away with from the Kernel summit. It's like they _want_ to keep it internal. Linus |
|
From: Dave A. <ai...@gm...> - 2009-12-11 00:47:15
|
2009/12/11 Linus Torvalds <tor...@li...>: > > > On Thu, 10 Dec 2009, "C. Bergström" wrote: >> >> Thanks for the rather lengthly explanation, but in case you missed what people >> are trying to say here.. >> >> With all due respect Linus.. >> >> "patches welcome" > > The problem is that I have never even heard a Red Hat or Fedora person > actually acknoledge that yes, they should be trying to upstream it. <Red Hat hat on> <Fedora hat on> We are trying to upstream nouveau. <Fedora hat off> <Red Hat hat off> <DRM maintainer hat on> The core DRM changes to support nouveau were but ugly, and shared with radeon and vmware, we need to wait for VMware to re-write them. VMware have rewritten them and they are upstream since radeon KMS got merged into staging. <DRM maintainer hat off> <nouveau reviewer hat on> The ctxprogs are legally dubious, we need to wait for Red Hat lawyers to give us some direction, we can involve other lawyers but more lawyers doesn't always help these things go faster. <nouveau reviewer hat off> <Dave hat on> nvidia guys are laughing at us. <Dave hat off> Dave. |
|
From: Kyle M. <ky...@mc...> - 2009-12-11 02:08:48
|
On Thu, Dec 10, 2009 at 04:32:56PM -0800, Linus Torvalds wrote: > > "patches welcome" > > The problem is that I have never even heard a Red Hat or Fedora person > actually acknoledge that yes, they should be trying to upstream it. > > Have Red Hat and Fedora just decided that "upstream first" simply doesn't > matter any more? Because quite frankly, that was kind of the feeling I > came away with from the Kernel summit. > Well, given that none of the Fedora kernel people were able to attend this year for a variety of reasons, this is an interesting revelation to me, I wasn't aware I thought this. I, for one, would very much like nouveau to be upstream. It would certainly make my life easier not having to worry about subtlely breaking graphics adapters I can't test whenever we rebase to new git changes in the DRM. Thankfully Ben and Dave have been ninja at dealing with it, otherwise I probably would have punted it by now. > It's like they _want_ to keep it internal. > regards, Kyle |
|
From: Alan C. <al...@lx...> - 2009-12-10 17:39:02
|
> Last time they were asked that, they wanted to be free of changing their > kernel/userspace interface before upstreaming. So put it in staging with a note to that effect. That'll also get it more exposure and review. Alan |
|
From: Ingo M. <mi...@el...> - 2009-12-10 22:29:37
|
* Alan Cox <al...@lx...> wrote: > > Last time they were asked that, they wanted to be free of changing their > > kernel/userspace interface before upstreaming. > > So put it in staging with a note to that effect. That'll also get it > more exposure and review. Well, arguably that particular idea should have come from the people maintaining that area of code. There's this one missing driver which covers (more or less) like 40%-50% of the PC market, that's a glaringly significant issue, isnt it? It doesnt get any more significant, does it? Ingo |
|
From: Dave A. <ai...@gm...> - 2009-12-10 19:37:35
|
On Fri, Dec 11, 2009 at 4:42 AM, Linus Torvalds <tor...@li...> wrote: > > > On Thu, 10 Dec 2009, Maarten Maathuis wrote: >> >> You assume that Red Hat has full control over the project, which i >> don't think is the case. The reason it isn't in staging yet (as far as >> i know) is because of some questions over the copyright of some >> (essential) microcode. Either the question needs to be answered, or it >> has to be reverse engineered to the point that it's possible to >> generate it. > > I think people are just making up excuses, as evidenced by the fact that > you're quoting a different excuse than I've heard before. > > The fact is, if there are license questions, then Fedora had better not be > distributing the code either. And they clearly are. Alan mentioned this at KS, Fedora shipping something and RH taking responsibility or something going upstream to you and then into multiple other distros that aren't RH controlled are completely different questions from the lawyers point of view. At the moment we cannot provide a Signed-off version of nouveau, I don't think you are willing to accept stuff without Signed-off-by's unless something has changed recently. > > And don't tell me about "full control". There's absolutely full control > over it being included or not. While its not Red Hat's decision, we pay one of the nouveau developers to work on it, but the project consists of a lot more than him, and RH generally doesn't order upstreams to do stuff they aren't comfortable with. If someone has time to take the nouveau patches and convert all the dubious pieces of code to firmware loader interface and set it up so the main code can be merged upstream and the firmware left to one side and someone else can possibly redistribute the firmware then it might happen quicker. Dave. |
|
From: Roland D. <rd...@ci...> - 2009-12-10 19:58:01
|
> If someone has time to take the nouveau patches and convert all the dubious > pieces of code to firmware loader interface and set it up so the main code > can be merged upstream and the firmware left to one side and someone > else can possibly redistribute the firmware then it might happen quicker. I don't have any nvidia hardware. Someone send me an ion netbook and I'll take care of converting nouveau to firmware loader :) - R. |
|
From: Pekka P. <pq...@ik...> - 2009-12-10 19:50:06
|
On Thu, 10 Dec 2009 10:42:46 -0800 (PST) Linus Torvalds <tor...@li...> wrote: > On Thu, 10 Dec 2009, Maarten Maathuis wrote: > > > > You assume that Red Hat has full control over the project, > > which i don't think is the case. The reason it isn't in staging > > yet (as far as i know) is because of some questions over the > > copyright of some (essential) microcode. Either the question > > needs to be answered, or it has to be reverse engineered to the > > point that it's possible to generate it. > > I think people are just making up excuses, as evidenced by the > fact that you're quoting a different excuse than I've heard > before. That is because priorities change. The ABI has not seen changes for some time now, so it's probably not an issue anymore. And it is not an issue for staging. The other issue has become more important. That said, there are features that likely require revising the ABI at some point, and we know about those already. > The fact is, if there are license questions, then Fedora had > better not be distributing the code either. And they clearly are. I've no idea how they pulled that, but I have not heard anyone say that there are *no* legal issues at all. > I've heard the "but it's hard to merge" excuse too - which I also > know is bullshit, because I can look at the git tree Fedora > apparently uses, and it merges without any conflicts what-so-ever. No-one has said that about Nouveau, have they? > The most common excuse is the "oh, but it might change" crap. But > that's not even a very good excuse to start with, and it's what > staging is for anyway. Yes, and to my understanding Nouveau is past that excuse. People just like to quote what they heard last. The big question is what we call ctxprogs: binary blobs that are clearly executable, running somewhere in the GPU. No-one seems to know, if those are copyrightable, or if they can be redistributed. In their current form, they have been recorded from the nvidia proprietary driver using mmiotrace, and copied verbatim for each card type. Would you be willing to pull that kind of stuff into Linux? I would not even dare sending them to the Linux firmware repository, since they have some license requirements, too. -- Pekka Paalanen http://www.iki.fi/pq/ |
|
From: Will D. <wil...@gm...> - 2009-12-10 20:35:20
|
On Thu, Dec 10, 2009 at 2:49 PM, Pekka Paalanen <pq...@ik...> wrote: > The big question is what we call ctxprogs: binary blobs that are > clearly executable, running somewhere in the GPU. No-one seems > to know, if those are copyrightable, or if they can be redistributed. > In their current form, they have been recorded from the nvidia > proprietary driver using mmiotrace, and copied verbatim for each > card type. > > Would you be willing to pull that kind of stuff into Linux? > > I would not even dare sending them to the Linux firmware > repository, since they have some license requirements, too. This seems similar to the unfortunate situation with the b43 wireless card firmware. Broadcom refuses to provide the firmware under a redistributable license (or even as files separate from their proprietary drivers). This did not stop b43 from being included in Linux. Distributions have dealt with it by providing a script that downloads the proprietary driver and extracts the firmware from it to files in /lib/firmware. Do you think that a similar solution for nouveau would be legally problematic? Or is the issue technical, since you mention that the ctxprogs were obtained by mmiotrace, instead of a more straightforward extraction from the binary driver blobs? -- Will Dyson |
|
From: Pekka P. <pq...@ik...> - 2009-12-10 21:12:43
|
On Thu, 10 Dec 2009 15:35:08 -0500 Will Dyson <wil...@gm...> wrote: > This seems similar to the unfortunate situation with the b43 > wireless card firmware. Broadcom refuses to provide the firmware > under a redistributable license (or even as files separate from > their proprietary drivers). This did not stop b43 from being > included in Linux. Distributions have dealt with it by providing > a script that downloads the proprietary driver and extracts the > firmware from it to files in /lib/firmware. > > Do you think that a similar solution for nouveau would be legally > problematic? Or is the issue technical, since you mention that the > ctxprogs were obtained by mmiotrace, instead of a more > straightforward extraction from the binary driver blobs? It is definitely a lot harder than a script that just downloads something. It would have to: - download the proprietary driver - install it and load it into the kernel - activate mmiotrace (if it even is compiled in) - reconfigure and start X and quit - analyse the mmiotrace log to extract the ctxprog and ctxvals - undo all the proprietary setup I cannot comment on the legal side, but the practise sounds too cumbersome. Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ |
|
From: Dave A. <ai...@gm...> - 2009-12-11 00:28:27
|
> > I realize that you have some emotional attachments to Red Hat, but ask > yourself (and answer honestly): what would you think if some random other > distro was packaging tens of thousands of lines of kernel code and not > apparently working at trying to get them upstream? Lots of distros do this all the time, you just don't have any hardware or care about it. If you didn't have an nvidia box you wouldn't care about this either. If I send you an LIRC remote will you bitch about LIRC not being upstream and Fedora/Ubuntu/everyone else shipping it? > > Dave claims it's only been going on for a few months, but quite frankly, > we all know better. The nouveau kernel modules have been shipped for a lot > longer than just F12. No I know exactly how long we've had the code in Fedora, it predates both mine and Ben's employment at Red Hat. But it doesn't change the fact the code has only in the last 2-3 months gotten to a stage where the core DRM code was able to support it, mainly due to radeon KMS work being pushed. Previous nouveau drivers shipped were either UMS with an API that nobody wanted upstream, or KMS with a reliance on a core DRM feature that no-one wanted upstream. We've been resolving those issues first, while hoping the lawyers could deal with ctxprogs, guess we moved faster than them. I'm going to see what Ben can do with a firmware loader and the ctxprogs, we can send a patch that contains all the other bits of the driver, however since the ctxprogs aren't currently something we can add Signed-off-by to, someone else will have to endeavour to provide them some other way. Dave. |
|
From: Linus T. <tor...@li...> - 2009-12-11 00:45:46
|
On Fri, 11 Dec 2009, Dave Airlie wrote: > > I'm going to see what Ben can do with a firmware loader and the ctxprogs, > we can send a patch that contains all the other bits of the driver, however > since the ctxprogs aren't currently something we can add Signed-off-by to, > someone else will have to endeavour to provide them some other way. Hey, thanks. This was actually the first time I got the feeling that you acknowledged that we should strive for it to be merged at all. I literally feel better for just that. Linus |
|
From: Stephane M. <ste...@gm...> - 2009-12-11 10:02:46
|
On Fri, Dec 11, 2009 at 00:58, Alan Cox <al...@lx...> wrote: >> But not only is Fedora not following the rules, > > You changed the rules. You require a Signed-off-by:. Fedora can no more > add a signed off by than you can. It's not their code nor Red Hat's code > any more than they "own" the kernel because they pay someone to work on > it. > >> See above. It's not you. It's Fedora. If Fedora hadn't merged Nouveau and >> shipped it, I wouldn't care. > > And zillions of Nvidia users would have been worse off. > > It's really simple: if you want to merge it *you* pull it and sign it off. > If you aren't prepared to do that then ask why Fedora should, its not > their code either. > So what, if someone outside RedHat is ok to sign it off, it can go into staging? If it's that simple I don't mind signing it off (including the dubious bits), I can take the blame if that helps things move forward. Stephane |
|
From: Andy W. <aw...@ra...> - 2009-12-11 10:42:30
|
On Fri, 2009-12-11 at 11:02 +0100, Stephane Marchesin wrote: > On Fri, Dec 11, 2009 at 00:58, Alan Cox <al...@lx...> wrote: > > It's really simple: if you want to merge it *you* pull it and sign it off. > > If you aren't prepared to do that then ask why Fedora should, its not > > their code either. > So what, if someone outside RedHat is ok to sign it off, it can go > into staging? If it's that simple I don't mind signing it off > (including the dubious bits), I can take the blame if that helps > things move forward. Could not a NAK by the author stop that? Regards, Andy |
|
From: Jeff G. <je...@ga...> - 2009-12-11 10:28:55
|
On 12/11/2009 04:18 AM, Alan Cox wrote: > F11 certainly shipped some bits of it for 2D support. I am not sure if > F10 shipped a purely userspace set up. Neither had it enabled as the > default driver - they used "nv" or "vesa" depending upon the card. F11 uses nouveau here. It is actually a pain to get 'nv' going as an alternate -- bugs have been filed. Makes kernel dev more difficult for me. I was actually told, by Fedora people, that I should be hacking on the Fedora (rpm-based) kernel, rather than a 100% upstream kernel like I have been hacking/booting for the past decade, as a result of this setup (needing nouveau kernel support, thus needing Fedora rather than upstream kernel). Jeff |
|
From: Dave A. <ai...@gm...> - 2009-12-11 10:46:25
|
On Fri, Dec 11, 2009 at 8:28 PM, Jeff Garzik <je...@ga...> wrote: > On 12/11/2009 04:18 AM, Alan Cox wrote: >> >> F11 certainly shipped some bits of it for 2D support. I am not sure if >> F10 shipped a purely userspace set up. Neither had it enabled as the >> default driver - they used "nv" or "vesa" depending upon the card. > > F11 uses nouveau here. It is actually a pain to get 'nv' going as an > alternate -- bugs have been filed. Makes kernel dev more difficult for me. > I was actually told, by Fedora people, that I should be hacking on the > Fedora (rpm-based) kernel, rather than a 100% upstream kernel like I have > been hacking/booting for the past decade, as a result of this setup (needing > nouveau kernel support, thus needing Fedora rather than upstream kernel). It wouldn't have helped the ABI was broken between F11 and now, so you'd be in the same boat putting this code upstream via staging in no way means you can run it with the F11 userspace or ongoing even with the F12 one. Dave. > > Jeff > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to maj...@vg... > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > |
|
From: Linus T. <tor...@li...> - 2009-12-11 15:29:49
|
On Fri, 11 Dec 2009, Jeff Garzik wrote: > > F11 uses nouveau here. It is actually a pain to get 'nv' going as an > alternate -- bugs have been filed. Makes kernel dev more difficult for me. I > was actually told, by Fedora people, that I should be hacking on the Fedora > (rpm-based) kernel, rather than a 100% upstream kernel like I have been > hacking/booting for the past decade, as a result of this setup (needing > nouveau kernel support, thus needing Fedora rather than upstream kernel). Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the wrong people - it's just that the actual driver authors aren't the ones that violated any rules), I do have to give kudos for the fact that the F12 situation seems to be much better. These days, what you can do is basically do all development (assuming it's not nouveau development) in the upstream kernel, and then you just have a separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff into. That tree/branch will be a mess of random merges-of-the-day, but you'll never push it out to anybody anyway, so nobody cares. And building that messy merge tree will get you a working setup without any extra steps - a simple "make modules_install ; make install" will JustWork(tm). So it's much more straightforward than it used to be (you had that separate tree that you could build modules in), you can basically build things exactly the same way you are supposed to do things _anyway_ if you have experimental branches etc and want to build in a temporary merged tree (even if you're not actually ready to merge it all and still want to keep the branches separate). Of course, it's a good thing that it's easier in F12, because in F11 if you forgot to build the nouveau stuff, it would just fall back on the VESA FB setup - you had a working system, it was just very slow X. You could then build the nouveau modules you forgot about, and re-start X. That "oops, I forgot" case seems to no longer work at all in F12 - if I build without Nouveau on my nvidia machine, the kernel will boot, but I will have neither working X _nor_ a working text login. So there's no way to even build the modules and fix it up - you have just to re-boot back into an old kernel. Very annoying for bisection. Linus |
|
From: Jeff G. <je...@ga...> - 2009-12-11 17:49:48
|
On 12/11/2009 10:28 AM, Linus Torvalds wrote: > > > On Fri, 11 Dec 2009, Jeff Garzik wrote: >> >> F11 uses nouveau here. It is actually a pain to get 'nv' going as an >> alternate -- bugs have been filed. Makes kernel dev more difficult for me. I >> was actually told, by Fedora people, that I should be hacking on the Fedora >> (rpm-based) kernel, rather than a 100% upstream kernel like I have been >> hacking/booting for the past decade, as a result of this setup (needing >> nouveau kernel support, thus needing Fedora rather than upstream kernel). > > Btw, for all my ranting (and maybe Alan is right, and I'm ranting at the > wrong people - it's just that the actual driver authors aren't the ones > that violated any rules), I do have to give kudos for the fact that the > F12 situation seems to be much better. > > These days, what you can do is basically do all development (assuming it's > not nouveau development) in the upstream kernel, and then you just have a > separate 'nouveau' git tree (or branch) that you pull in the nouvea stuff > into. > > That tree/branch will be a mess of random merges-of-the-day, but you'll > never push it out to anybody anyway, so nobody cares. And building that > messy merge tree will get you a working setup without any extra steps - a > simple "make modules_install ; make install" will JustWork(tm). At the outset, I was hoping for an even more straightforward solution: "if nouveau kernel mod not present, fall back to nv" That would work without any kernel modifications at all. But the answer came back as "if you run Fedora, run a Fedora kernel, otherwise don't expect anything to work" My experience directly contradicts claims of "upstream first" policy, both in code and attitude. I am looking into doing the git tree merge you suggest right now.... I didn't know that was an option, given ongoing API changes. That would make my life quite a bit easier. As you note, anything graphics is _glacially_ slow due to vesa fallback, when using a 100% upstream kernel. Jeff |
|
From: Dave A. <ai...@li...> - 2010-01-11 04:52:54
|
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This contains 3 trees: core: two KMS fixes, one for a regression I found with Fedora's plymouth on my r100 laptop with an 8-bpp console, the other for unwanted outputs lighting up on resume. radeon kms: a regression fix since we added host data flushing support some users reported r300s dying under load, this change fixes that, along with better s/r support for gpus with sideport RAM, along with eDP support (needed for new imacs to display anything). Also we sync'ed the whitespace in ObjectID.h with all the other copies to make syncing them with AMD's master copy easier, its not kernel compliant but it is a lot easier to work with for AMD. nouveau: scattering of fixes from the nouveau upstream tree. Dave. drivers/gpu/drm/drm_crtc.c | 1 + drivers/gpu/drm/drm_crtc_helper.c | 26 +- drivers/gpu/drm/drm_fb_helper.c | 9 +- drivers/gpu/drm/drm_irq.c | 5 +- drivers/gpu/drm/nouveau/Kconfig | 5 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 243 ++++++--- drivers/gpu/drm/nouveau/nouveau_channel.c | 47 +-- drivers/gpu/drm/nouveau/nouveau_dma.c | 34 +- drivers/gpu/drm/nouveau/nouveau_dma.h | 10 +- drivers/gpu/drm/nouveau/nouveau_drv.h | 72 ++- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 19 +- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 1 + drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 33 +- drivers/gpu/drm/nouveau/nouveau_irq.c | 1 + drivers/gpu/drm/nouveau/nouveau_mem.c | 87 +++ drivers/gpu/drm/nouveau/nouveau_object.c | 2 +- drivers/gpu/drm/nouveau/nouveau_reg.h | 16 +- drivers/gpu/drm/nouveau/nouveau_state.c | 27 +- drivers/gpu/drm/nouveau/nouveau_ttm.c | 30 +- drivers/gpu/drm/nouveau/nv04_dac.c | 35 +- drivers/gpu/drm/nouveau/nv04_fbcon.c | 41 +- drivers/gpu/drm/nouveau/nv04_fifo.c | 34 ++ drivers/gpu/drm/nouveau/nv04_graph.c | 159 +++--- drivers/gpu/drm/nouveau/nv10_fb.c | 32 +- drivers/gpu/drm/nouveau/nv10_graph.c | 28 +- drivers/gpu/drm/nouveau/nv17_tv.c | 115 ++++- drivers/gpu/drm/nouveau/nv20_graph.c | 61 +-- drivers/gpu/drm/nouveau/nv40_fb.c | 53 ++- drivers/gpu/drm/nouveau/nv40_graph.c | 116 ++--- drivers/gpu/drm/nouveau/nv50_display.c | 17 + drivers/gpu/drm/nouveau/nv50_fbcon.c | 23 +- drivers/gpu/drm/nouveau/nv50_fifo.c | 6 +- drivers/gpu/drm/radeon/Makefile | 5 + drivers/gpu/drm/radeon/ObjectID.h | 801 +++++++++++++++------------- drivers/gpu/drm/radeon/atombios_dp.c | 6 +- drivers/gpu/drm/radeon/mkregtable.c | 4 +- drivers/gpu/drm/radeon/r100.c | 23 +- drivers/gpu/drm/radeon/r300.c | 17 +- drivers/gpu/drm/radeon/r420.c | 41 ++- drivers/gpu/drm/radeon/r520.c | 1 + drivers/gpu/drm/radeon/r600.c | 21 +- drivers/gpu/drm/radeon/r600_blit_kms.c | 4 +- drivers/gpu/drm/radeon/radeon.h | 9 +- drivers/gpu/drm/radeon/radeon_agp.c | 6 +- drivers/gpu/drm/radeon/radeon_asic.h | 12 - drivers/gpu/drm/radeon/radeon_atombios.c | 41 ++- drivers/gpu/drm/radeon/radeon_combios.c | 14 + drivers/gpu/drm/radeon/radeon_connectors.c | 23 +- drivers/gpu/drm/radeon/radeon_display.c | 7 +- drivers/gpu/drm/radeon/radeon_encoders.c | 14 +- drivers/gpu/drm/radeon/radeon_gem.c | 2 - drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 +- drivers/gpu/drm/radeon/radeon_legacy_tv.c | 14 +- drivers/gpu/drm/radeon/radeon_mode.h | 26 - drivers/gpu/drm/radeon/radeon_object.c | 5 +- drivers/gpu/drm/radeon/reg_srcs/r420 | 795 +++++++++++++++++++++++++++ drivers/gpu/drm/radeon/reg_srcs/rs600 | 68 +++- drivers/gpu/drm/radeon/reg_srcs/rv515 | 6 + drivers/gpu/drm/radeon/rs400.c | 2 + drivers/gpu/drm/radeon/rs600.c | 10 +- drivers/gpu/drm/radeon/rs690.c | 2 + drivers/gpu/drm/radeon/rv515.c | 1 + drivers/gpu/drm/radeon/rv770.c | 3 +- include/drm/drm_mode.h | 1 + 65 files changed, 2411 insertions(+), 973 deletions(-) create mode 100644 drivers/gpu/drm/radeon/reg_srcs/r420 commit f22d6ddaeb8126623d62c828a4d4a96dfc4cbc5c Merge: 0c9d2c4 40c2298 Author: Dave Airlie <ai...@re...> Date: Mon Jan 11 14:43:16 2010 +1000 Merge branch 'for-airlied' of /ssd/git/drm-nouveau-next into drm-linus * 'for-airlied' of /ssd/git/drm-nouveau-next: (28 commits) drm/nv04: Fix set_operation software method. drm/nouveau: initialise DMA tracking parameters earlier drm/nouveau: use dma.max rather than pushbuf size for checking GET validity drm/nv04: differentiate between nv04/nv05 drm/nouveau: Fix null deref in nouveau_fence_emit due to deleted fence drm/nv50: prevent a possible ctxprog hang drm/nouveau: have ttm's fault handler called directly drm/nv50: restore correct cache1 get/put address on fifoctx load drm/nouveau: create function for "dealing" with gpu lockup drm/nouveau: remove unused nouveau_channel_idle() function drm/nouveau: fix handling of fbcon colours in 8bpp drm/nv04: Context switching fixes. drm/nouveau: Use the software object for fencing. drm/nouveau: Allocate a per-channel instance of NV_SW. drm/nv50: make the blocksize depend on vram size drm/nouveau: better alignment of bo sizes and use roundup instead of ALIGN drm/nouveau: Don't skip card take down on nv0x. drm/nouveau: Implement nv42-nv43 TV load detection. drm/nouveau: Clean up the nv17-nv4x load detection code a bit. drm/nv50: fix fillrect color ... commit 0c9d2c418aa4a45534943c4c9a1c8dda82d3b481 Merge: 94fd163 804c755 Author: Dave Airlie <ai...@re...> Date: Mon Jan 11 14:42:58 2010 +1000 Merge remote branch 'korg/drm-radeon-next' into drm-linus * korg/drm-radeon-next: drm/radeon/kms: add additional safe regs for r4xx/rs6xx and r5xx drm/radeon/kms: Don't try to enable IRQ if we have no handler installed drm: Avoid calling vblank function is vblank wasn't initialized drm/radeon: mkregtable.c: close a file before exit drm/radeon/kms: Make sure we release AGP device if we acquired it drm/radeon/kms: Schedule host path read cache flush through the ring V2 drm/radeon/kms: Workaround RV410/R420 CP errata (V3) drm/radeon/kms: detect sideport memory on IGP chips drm/radeon: fix a couple of array index errors drm/radeon/kms: add support for eDP (embedded DisplayPort) drm: Add eDP connector type drm/radeon/kms: pull in the latest upstream ObjectID.h changes drm/radeon/kms: whitespace changes to ObjectID.h drm/radeon/kms: fix typo in atom connector type handling commit 40c2298bdcc8b766a39964c44e9a74d16aa95d53 Author: Marcin Kościelnicki <kor...@0x...> Date: Sun Jan 10 17:09:14 2010 +0000 drm/nv04: Fix set_operation software method. Signed-off-by: Ben Skeggs <bs...@re...> commit c63834e1db41b59d6c7bfb1d2a549c027a42a877 Author: Ben Skeggs <bs...@re...> Date: Fri Jan 8 10:57:39 2010 +1000 drm/nouveau: initialise DMA tracking parameters earlier Signed-off-by: Ben Skeggs <bs...@re...> commit 400f14ac4ef02b2f77c9d0e3ad7d66e2f6c8e663 Author: Ben Skeggs <bs...@re...> Date: Fri Jan 8 10:53:40 2010 +1000 drm/nouveau: use dma.max rather than pushbuf size for checking GET validity Some upcoming G80 DMA changes will depend on this, but it's split out for bisectibility just in case it causes some unexpected issues. Signed-off-by: Ben Skeggs <bs...@re...> commit cc6e496587502057af02139931736b0b7a49f637 Author: Ben Skeggs <bs...@re...> Date: Thu Jan 7 13:47:57 2010 +1000 drm/nv04: differentiate between nv04/nv05 Signed-off-by: Ben Skeggs <bs...@re...> commit d6126c5c8b2019658aadc9754dca80a7573dbff5 Author: Luca Barbieri <lu...@lu...> Date: Wed Jan 6 04:02:45 2010 +0100 drm/nouveau: Fix null deref in nouveau_fence_emit due to deleted fence Currently Nouveau will unvalidate all buffers if it is forced to wait on one, and then start revalidating from the beginning. While doing so, it destroys the operation fence, causing nouveau_fence_emit to crash. This patch fixes this bug by taking the fence object out of validate_op and creating it just before emit. The fence pointer is initialized to 0 and unref'ed unconditionally. In addition to fixing the bug, this prevents its reintroduction and simplifies the code. Signed-off-by: Luca Barbieri <lu...@lu...> Signed-off-by: Ben Skeggs <bs...@re...> commit dc8d76cac942e7344a72ad18afb90fa46cf20bb4 Author: Ben Skeggs <bs...@re...> Date: Wed Jan 6 12:00:02 2010 +1000 drm/nv50: prevent a possible ctxprog hang The below is mainly an educated guess at what's going on, docs would sure be handy... NVIDIA? :P It appears it's possible for a ctxprog to run even while a GPU exception is pending. The GF8 and up ctxprogs appear to have a small snippet of code which detects this, and stalls the ctxprog until it's been handled, which essentially looks like: if (r2 & 0x00008000) { r0 |= 0x80000000; while (r0 & 0x80000000) {} } I don't know of any way that flag would get cleared unless the driver intervenes (and indeed, in the cases I've seen the hang, nothing steps in to automagically clear it for us). This patch causes the driver to clear the flag during the PGRAPH IRQ handler. Signed-off-by: Ben Skeggs <bs...@re...> commit 1959ca80e1f88b82c1cb7227f437910768ab0c94 Author: Ben Skeggs <bs...@re...> Date: Mon Jan 4 15:52:20 2010 +1000 drm/nouveau: have ttm's fault handler called directly There's no good reason for us to have our own anymore, this is left over from an early port to these TTM interfaces. Signed-off-by: Ben Skeggs <bs...@re...> commit a908b96c22883f967e4ddf5aa5b35e3b4a0629a5 Author: Ben Skeggs <bs...@re...> Date: Tue Jan 5 09:41:05 2010 +1000 drm/nv50: restore correct cache1 get/put address on fifoctx load Signed-off-by: Ben Skeggs <bs...@re...> commit c03ec7f91fcf20af177dbc728d518fb462bad42d Author: Marcin Slusarz <mar...@gm...> Date: Mon Jan 4 19:25:09 2010 +0100 drm/nouveau: create function for "dealing" with gpu lockup It's mostly a cleanup, but in nv50_fbcon_accel_init gpu lockup message was printed, but HWACCEL_DISBALED flag was not set. Signed-off-by: Marcin Slusarz <mar...@gm...> Signed-off-by: Ben Skeggs <bs...@re...> commit e9dd8e11edfff5e348f3dcfd152a70c5da921126 Author: Ben Skeggs <bs...@re...> Date: Mon Jan 4 12:53:01 2010 +1000 drm/nouveau: remove unused nouveau_channel_idle() function Signed-off-by: Ben Skeggs <bs...@re...> commit 7de3643f938af910bef4c1f800176a3ebdc29502 Author: Ben Skeggs <bs...@re...> Date: Mon Jan 4 09:10:55 2010 +1000 drm/nouveau: fix handling of fbcon colours in 8bpp Depending on the visual, the colours handed to us in fillrect() can either be an actual colour, or an index into the pseudo-palette. Signed-off-by: Ben Skeggs <bs...@re...> commit ea911a1cf4f9c5bef18ff399ee2e2ec77792b650 Author: Francisco Jerez <cur...@ri...> Date: Sat Dec 26 14:39:46 2009 +0100 drm/nv04: Context switching fixes. Signed-off-by: Francisco Jerez <cur...@ri...> commit a5027ccd3c1abe190d2b84a2d7e40d5f099e48a7 Author: Francisco Jerez <cur...@ri...> Date: Sat Dec 26 02:09:36 2009 +0100 drm/nouveau: Use the software object for fencing. This should avoid a race condition on nv0x, if we're doing it with actual PGRAPH objects and a there's a fence within the FIFO DMA fetch area when a context switch kicks in. In that case we get an ILLEGAL_MTHD interrupt as expected, but the values in PGRAPH_TRAPPED_ADDR aren't calculated correctly and they're almost useless (e.g. you can see ILLEGAL_MTHDs for the now inactive channel, with a wrong offset/data pair). Signed-off-by: Francisco Jerez <cur...@ri...> commit ca4362adb4c01807dfcf3f2b3152a7ee36f0d1ca Author: Francisco Jerez <cur...@ri...> Date: Sat Dec 26 02:42:45 2009 +0100 drm/nouveau: Allocate a per-channel instance of NV_SW. It will be useful for various synchronization purposes, mostly stolen from "[PATCH] drm/nv50: synchronize user channel after buffer object move on kernel channel" by Maarten Maathuis. Signed-off-by: Francisco Jerez <cur...@ri...> commit 0a2d090f99c9686e5107ed59533fc4210a9a47d1 Author: Maarten Maathuis <mad...@gm...> Date: Sat Dec 26 21:46:36 2009 +0100 drm/nv50: make the blocksize depend on vram size - This should be better than what we have now. - I'm less sure about the non power of two path. Signed-off-by: Maarten Maathuis <mad...@gm...> commit c2b82924bda0c3de2b49bd3a4d8b6725721820bc Author: Maarten Maathuis <mad...@gm...> Date: Fri Dec 25 18:51:17 2009 +0100 drm/nouveau: better alignment of bo sizes and use roundup instead of ALIGN - Aligning to block size should ensure that the extra size is enough. - Using roundup, because not all sizes are powers of two. Signed-off-by: Maarten Maathuis <mad...@gm...> commit 8f71c29e442e013212a98e2b37eb1074c4d1134f Author: Francisco Jerez <cur...@ri...> Date: Tue Dec 22 18:24:09 2009 +0100 drm/nouveau: Don't skip card take down on nv0x. Signed-off-by: Francisco Jerez <cur...@ri...> commit b7f7e41b895afd110d1f5121161fd401eccd98c9 Author: Francisco Jerez <cur...@ri...> Date: Thu Dec 17 18:57:44 2009 +0100 drm/nouveau: Implement nv42-nv43 TV load detection. Signed-off-by: Francisco Jerez <cur...@ri...> commit 02076da97a15bbf7477bffed71d02f726de2afc2 Author: Francisco Jerez <cur...@ri...> Date: Thu Dec 17 18:52:44 2009 +0100 drm/nouveau: Clean up the nv17-nv4x load detection code a bit. Signed-off-by: Francisco Jerez <cur...@ri...> commit e55ca7e68efc7c2d320cd9975ebc5e0fd27debf0 Author: Marcin Slusarz <mar...@gm...> Date: Mon Dec 21 23:00:41 2009 +0100 drm/nv50: fix fillrect color struct fb_fillrect->color is not a color, but index into pseudo_palette array Signed-off-by: Marcin Slusarz <mar...@gm...> Signed-off-by: Ben Skeggs <bs...@re...> commit fbe36a7a069267b82b7b82a66d79a4406cfa90b2 Author: Ben Skeggs <bs...@re...> Date: Mon Dec 21 12:16:52 2009 +1000 drm/nv50: ignore vbios table's claim to the contrary if EDID says >8bpc Should fix dim panel issues reported on Dell M6400/M6500. Signed-off-by: Ben Skeggs <bs...@re...> commit aeca15e596eba284c727049d0b9b855b13c48856 Author: Francisco Jerez <cur...@ri...> Date: Wed Dec 16 19:03:28 2009 +0100 drm/nouveau: Drop redundant placement initialization. Signed-off-by: Francisco Jerez <cur...@ri...> commit 69a18c328b762eaec3f8ca3af8c7cbf10b536bf8 Author: Francisco Jerez <cur...@ri...> Date: Wed Dec 16 19:05:38 2009 +0100 drm/nouveau: No need to force evict=true when swapping evicted BOs back in. Signed-off-by: Francisco Jerez <cur...@ri...> commit c6af6053be60840dcbb037c3798557cbf71cbb08 Author: Francisco Jerez <cur...@ri...> Date: Wed Dec 16 19:05:00 2009 +0100 drm/nouveau: Fix "general protection fault" in the flipd/flips eviction path. Signed-off-by: Francisco Jerez <cur...@ri...> commit 73cb9276fd189c19558a97600456bd13fa5debe8 Author: Francisco Jerez <cur...@ri...> Date: Wed Dec 16 12:27:11 2009 +0100 drm/i2c/ch7006: Drop build time dependency to nouveau. This partially reverts e4b41066, as this driver is intended to be useful with any KMS driver for suitable hardware. The missing build dependency that commit workarounded was DRM_KMS_HELPER. Signed-off-by: Francisco Jerez <cur...@ri...> commit 287c1532145b63d394060d46c0309b123b862345 Author: Francisco Jerez <cur...@ri...> Date: Fri Dec 11 16:51:09 2009 +0100 drm/nouveau: Make the MM aware of pre-G80 tiling. This commit has also the following 3 bugfix commits squashed into it from the nouveau git tree: drm/nouveau: Fix up the tiling alignment restrictions for nv1x. drm/nouveau: Fix up the nv2x tiling alignment restrictions. drm/nv50: fix align typo for g9x Signed-off-by: Francisco Jerez <cur...@ri...> commit 0d87c100312ce75d9bb75a456d8a542e84a1722f Author: Francisco Jerez <cur...@ri...> Date: Wed Dec 16 12:12:27 2009 +0100 drm/nouveau: Pre-G80 tiling support. Signed-off-by: Francisco Jerez <cur...@ri...> commit 617e234b01757698ed5f8c9a5fbf12717b76e371 Author: Francisco Jerez <cur...@ri...> Date: Sun Dec 13 20:07:42 2009 +0100 drm/nouveau: Add cache_flush/pull fifo engine functions. Signed-off-by: Francisco Jerez <cur...@ri...> commit 94fd163d86b049842856864cdeac318131ec576d Author: Dave Airlie <ai...@re...> Date: Mon Jan 11 14:20:55 2010 +1000 drm: reduce WARN_ON to a printk. Lots of ppl keep thinking this is an oops, it was just a warning for me to see, just make it a printk now. Signed-off-by: Dave Airlie <ai...@re...> commit 509c7d83c3b18a50a0bd02afa43c8ee3c7605bc9 Author: Dave Airlie <ai...@re...> Date: Fri Jan 8 09:27:08 2010 +1000 drm/kms/fb: check for depth changes from userspace for resizing. If userspace (plymouth in this case) asks for a deeper depth, refuse it as well due to lack of resizing. This fixes an issue since < 32MB cards went to 8bpp and plymouth crashes on startup. Signed-off-by: Dave Airlie <ai...@re...> commit 89347bb8ef2d0af1ae8d847b7df91e9f04eccf2a Author: David John <dav...@xe...> Date: Thu Dec 31 12:00:46 2009 +0530 drm: Keep disabled outputs disabled after suspend / resume With the current DRM code, an output that has been powered off from userspace will automatically power back on when resuming from suspend. This patch fixes this behaviour. Tested only with the Intel i915 driver on an Intel GM45 Express chipset. Signed-off-by: David John <dav...@xe...> Reviewed-by: Jesse Barnes <jb...@vi...> Signed-off-by: Dave Airlie <ai...@re...> commit 804c7559e9376c3ba78ae15a30337b1e24f8ae80 Author: Alex Deucher <ale...@gm...> Date: Fri Jan 8 15:58:49 2010 -0500 drm/radeon/kms: add additional safe regs for r4xx/rs6xx and r5xx - r4xx/rs6xx: add support for extended pixel shader instruction/temp regs - r5xx: add SM3 regs Signed-off-by: Alex Deucher <ale...@gm...> Signed-off-by: Dave Airlie <ai...@re...> commit 003e69f9862bcda89a75c27750efdbc17ac02945 Author: Jerome Glisse <jg...@re...> Date: Thu Jan 7 15:39:14 2010 +0100 drm/radeon/kms: Don't try to enable IRQ if we have no handler installed If for any reason we haven't installed handler we shouldn't try to enable IRQ/MSI on the hw so we don't get unhandled IRQ/MSI which makes the kernel sad. Signed-off-by: Jerome Glisse <jg...@re...> Signed-off-by: Dave Airlie <ai...@re...> commit e77cef9c2d87db835ad9d70cde4a9b00b0ca2262 Author: Jerome Glisse <jg...@re...> Date: Thu Jan 7 15:39:13 2010 +0100 drm: Avoid calling vblank function is vblank wasn't initialized In some case vblank might not be initialized and we shouldn't try to use associated function. This patch make sure this is the case. It also export drm_vblank_cleanup so driver can cleanup vblank if for any reason IRQ/MSI is not working. Signed-off-by: Jerome Glisse <jg...@re...> Signed-off-by: Dave Airlie <ai...@re...> commit 059d233f9c1183ed2f59d631e4daf486060e880d Author: Alexander Beregalov <a.b...@gm...> Date: Thu Jan 7 02:59:31 2010 +0300 drm/radeon: mkregtable.c: close a file before exit Signed-off-by: Alexander Beregalov <a.b...@gm...> Signed-off-by: Dave Airlie <ai...@re...> commit d0269ed8580b492df75dafb011dc51a1390bf200 Author: Jerome Glisse <jg...@re...> Date: Thu Jan 7 16:08:32 2010 +0100 drm/radeon/kms: Make sure we release AGP device if we acquired it In some case we weren't releasing the AGP device at module unloading. This leaded to unfunctional AGP at next module load. This patch make sure we release the AGP bus if we acquire it. Signed-off-by: Jerome Glisse <jg...@re...> Signed-off-by: Dave Airlie <ai...@re...> commit cafe6609d6dc0a6a278f9fdbb59ce4d761a35ddd Author: Jerome Glisse <jg...@re...> Date: Thu Jan 7 12:39:21 2010 +0100 drm/radeon/kms: Schedule host path read cache flush through the ring V2 R300 family will hard lockup if host path read cache flush is done through MMIO to HOST_PATH_CNTL. But scheduling same flush through ring seems harmless. This patch remove the hdp_flush callback and add a flush after each fence emission which means a flush after each IB schedule. Thus we should have same behavior without the hard lockup. Tested on R100,R200,R300,R400,R500,R600,R700 family. V2: Adjust fence counts in r600_blit_prepare_copy() Signed-off-by: Jerome Glisse <jg...@re...> Reviewed-by: Alex Deucher <ale...@gm...> Signed-off-by: Dave Airlie <ai...@re...> commit 62cdc0c20663ef840a94850892517b2b7f584904 Author: Corbin Simpson <Mos...@gm...> Date: Wed Jan 6 19:28:48 2010 +0100 drm/radeon/kms: Workaround RV410/R420 CP errata (V3) Long story short, this fixes sporadic hardlocks with my rv410 during times of intense 2D acceleration (Flash on Fx3). V2: Fix indentation and move errata_fini to suspend function so we don't leak scratch register over suspend/resume cycle. V3: Move scratch_reg to asic specific structure (aim is to slowly move stuff to asic specific structure and avoid poluting radeon_device struct with asic specific variables) Signed-off-by: Corbin Simpson <Mos...@gm...> Signed-off-by: Jerome Glisse <jg...@re...> Signed-off-by: Dave Airlie <ai...@re...> commit 06b6476d6b291473d0928ed242158a001d50c0f0 Author: Alex Deucher <ale...@gm...> Date: Tue Jan 5 11:27:29 2010 -0500 drm/radeon/kms: detect sideport memory on IGP chips This detects if the sideport memory is enabled and if it is VRAM is evicted on suspend/resume. This should fix s/r issues on some IGPs. Signed-off-by: Alex Deucher <ale...@gm...> Signed-off-by: Dave Airlie <ai...@re...> commit fc9a89f97e532152ae614d5ce717b81c8f8b0e91 Author: Darren Jenkins <dar...@gm...> Date: Thu Jan 7 01:35:21 2010 -0500 drm/radeon: fix a couple of array index errors There are a couple of array overruns, and some associated confusion in the code. This is just a wild guess at what the code should actually look like. Coverity CID: 13305 13306 agd5f: fix up the original intent of the timing code Signed-off-by: Darren Jenkins <dar...@gm...> Signed-off-by: Alex Deucher <ale...@gm...> Signed-off-by: Dave Airlie <ai...@re...> commit 196c58d21fc47fbabab6a98e23e5a6335f717e44 Author: Alex Deucher <ale...@gm...> Date: Thu Jan 7 14:22:32 2010 -0500 drm/radeon/kms: add support for eDP (embedded DisplayPort) This is displayport used for internal connections such as laptop panels and systems with integrated monitors. Signed-off-by: Alex Deucher <ale...@gm...> Signed-off-by: Dave Airlie <ai...@re...> commit 7970e677accb676f15e11468c60cb93ae477a513 Author: Alex Deucher <ale...@gm...> Date: Thu Jan 7 13:47:47 2010 -0500 drm: Add eDP connector type Add a new connector type for eDP (embedded displayport) eDP is more or less the same as DP but there are some cases when you might want to handle it separately. Signed-off-by: Alex Deucher <ale...@gm...> Signed-off-by: Dave Airlie <ai...@re...> commit f0f480adcb6c44e76186c6d3036e06ed7e7e0202 Author: Alex Deucher <ale...@gm...> Date: Thu Jan 7 11:39:07 2010 -0500 drm/radeon/kms: pull in the latest upstream ObjectID.h changes Signed-off-by: Alex Deucher <ale...@gm...> Signed-off-by: Dave Airlie <ai...@re...> commit a7bc115fffb69a55cf2c332567ea6908d9026f22 Author: Alex Deucher <ale...@gm...> Date: Thu Jan 7 11:35:48 2010 -0500 drm/radeon/kms: whitespace changes to ObjectID.h Makes it easier to keep in sync with ddx and the upstream AMD versions. Signed-off-by: Alex Deucher <ale...@gm...> Signed-off-by: Dave Airlie <ai...@re...> commit a5899fcc189e9357873ddf26d5e6e7e6ff84c2f4 Author: Alex Deucher <ale...@gm...> Date: Thu Jan 7 14:19:47 2010 -0500 drm/radeon/kms: fix typo in atom connector type handling Also remove the problematic enums that were unused remnants from the ddx. Signed-off-by: Alex Deucher <ale...@gm...> Signed-off-by: Dave Airlie <ai...@re...> |
|
From: Dave A. <ai...@li...> - 2010-02-11 04:20:29
|
Hi Linus,
vmware + nouveau staging fixes are the bulk of this.
one vgaarb patch that I found in mmtom but can't find in my inbox for some
reason ah well better late than never.
radeon: fix the Kconfig msg to be more explicit, and some oops crashers
in the presence of bad bioses, along with a get rid of stupid white
borders on fbcon patch.
The following changes since commit e28cab42f384745c8a947a9ccd51e4aae52f5d51:
Linus Torvalds (1):
Merge branch 'i2c-for-linus' of git://git.kernel.org/.../jdelvare/staging
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
Andy Getzendanner (1):
vgaarb: fix incorrect dereference of userspace pointer.
Ben Skeggs (5):
drm/nouveau: fix non-vram notifier blocks
drm/nv40: make INIT_COMPUTE_MEM a NOP, just like nv50
drm/nouveau: make dp auxch xfer len check for reads only
drm/nv50: prevent multiple init tables being parsed at the same time
drm/nv50: disregard dac outputs in nv50_sor_dpms()
Dave Airlie (7):
drm/radeon/kms: change Kconfig text to reflect the new option.
drm/radeon/kms: don't crash if no DDC bus on VGA/DVI connector.
drm/radeon/kms: add quirk for VGA without DDC on rv730 XFX card.
drm/radeon/kms: fix screen clearing before fbcon.
Merge remote branch 'nouveau/for-airlied' of nouveau-2.6
drm/radeon/kms: retry auxch on 0x20 timeout value.
Merge branch 'drm-radeon-linus' of ../drm-next
Francisco Jerez (1):
drm/nouveau: Fixup semaphores on pre-nv50 cards.
Jakob Bornecrantz (2):
drm/vmwgfx: Report propper framebuffer_{max|min}_{width|height}
drm/vmwgfx: Drop scanout flag compat and add execbuf ioctl parameter members. Bumps major.
Julia Lawall (1):
drivers/gpu/drm/nouveau/nouveau_grctx.c: correct NULL test
Luca Barbieri (1):
drm/nouveau: call ttm_bo_wait with the bo lock held to prevent hang
Maarten Maathuis (4):
drm/nv50: align size of buffer object to the right boundaries.
drm/nv50: avoid unloading pgraph context when ctxprog is running
drm/nv50: delete ramfc object after disabling fifo, not before
drm/nv50: make the pgraph irq handler loop like the pre-nv50 version
Marcin Kościelnicki (4):
drm/nouveau: Add module options to disable acceleration.
drm/nouveau: Add getparam to get available PGRAPH units.
drm/nouveau: Fix fbcon on mixed pre-NV50 + NV50 multicard.
drm/nouveau: Add proper vgaarb support.
Marcin Slusarz (1):
drm/nouveau: move dereferences after null checks
Matthew Garrett (1):
nouveau: fix state detection with switchable graphics
Pauli Nieminen (1):
drm/radeon: Skip dma copy test in benchmark if card doesn't have dma engine.
Rafał Miłecki (1):
drm/radeon/kms: suspend and resume audio stuff
Thomas Hellstrom (2):
drm/vmwgfx: Update the user-space interface.
drm/vmwgfx: Fix a circular locking dependency bug.
drivers/gpu/drm/nouveau/nouveau_acpi.c | 12 +-
drivers/gpu/drm/nouveau/nouveau_bios.c | 19 ++--
drivers/gpu/drm/nouveau/nouveau_bios.h | 2 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +-
drivers/gpu/drm/nouveau/nouveau_channel.c | 7 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 7 +-
drivers/gpu/drm/nouveau/nouveau_dp.c | 10 +-
drivers/gpu/drm/nouveau/nouveau_drv.c | 10 ++-
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 40 +++++++-
drivers/gpu/drm/nouveau/nouveau_fbcon.h | 6 +
drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +
drivers/gpu/drm/nouveau/nouveau_grctx.c | 4 +-
drivers/gpu/drm/nouveau/nouveau_irq.c | 155 ++++++++++++++++-----------
drivers/gpu/drm/nouveau/nouveau_notifier.c | 13 ++-
drivers/gpu/drm/nouveau/nouveau_object.c | 3 +-
drivers/gpu/drm/nouveau/nouveau_reg.h | 1 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 7 +-
drivers/gpu/drm/nouveau/nouveau_state.c | 49 +++++++--
drivers/gpu/drm/nouveau/nv04_fbcon.c | 9 +-
drivers/gpu/drm/nouveau/nv50_crtc.c | 11 ++-
drivers/gpu/drm/nouveau/nv50_fbcon.c | 9 +-
drivers/gpu/drm/nouveau/nv50_fifo.c | 9 +-
drivers/gpu/drm/nouveau/nv50_graph.c | 10 ++-
drivers/gpu/drm/nouveau/nv50_sor.c | 1 +
drivers/gpu/drm/radeon/Kconfig | 12 ++-
drivers/gpu/drm/radeon/atombios_dp.c | 10 ++-
drivers/gpu/drm/radeon/r600.c | 8 ++
drivers/gpu/drm/radeon/r600_audio.c | 3 +-
drivers/gpu/drm/radeon/radeon_atombios.c | 9 ++
drivers/gpu/drm/radeon/radeon_benchmark.c | 55 ++++++----
drivers/gpu/drm/radeon/radeon_connectors.c | 20 ++--
drivers/gpu/drm/radeon/radeon_display.c | 11 ++-
drivers/gpu/drm/radeon/radeon_fb.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 11 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 17 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 6 +
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 13 +--
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 16 +---
drivers/gpu/vga/vgaarb.c | 2 +-
include/drm/nouveau_drm.h | 1 +
include/drm/vmwgfx_drm.h | 20 +++-
43 files changed, 402 insertions(+), 230 deletions(-) |
|
From: Christian B. <bor...@de...> - 2010-02-15 12:58:19
|
Am Donnerstag 11 Februar 2010 05:20:07 schrieb Dave Airlie: Dave, I just updated from to rc8 and got the a scheduling while atomic warning in nouveau. (see below). ... [ 0.298265] [drm] Initialized drm 1.1.0 20060810 [ 0.298409] nouveau 0000:01:00.0: power state changed by ACPI to D0 [ 0.298420] nouveau 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 0.298426] nouveau 0000:01:00.0: setting latency timer to 64 [ 0.301746] [drm] nouveau 0000:01:00.0: failed to evaluate _DSM: 5 [ 0.303750] ACPI: Battery Slot [BAT0] (battery present) [ 0.304515] [drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x084c00a2) [ 0.305534] [drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN [ 0.382604] [drm] nouveau 0000:01:00.0: ... appears to be valid [ 0.382607] [drm] nouveau 0000:01:00.0: BIT BIOS found [ 0.382609] [drm] nouveau 0000:01:00.0: Bios version 60.84.51.00 [ 0.382613] [drm] nouveau 0000:01:00.0: TMDS table revision 2.0 not currently supported [ 0.382614] [drm] nouveau 0000:01:00.0: BIT table 'd' not found [ 0.382616] [drm] nouveau 0000:01:00.0: Found Display Configuration Block version 4.0 [ 0.382619] [drm] nouveau 0000:01:00.0: DCB connector table: VHER 0x40 5 14 2 [ 0.382621] [drm] nouveau 0000:01:00.0: 0: 0x00000040: type 0x40 idx 0 tag 0xff [ 0.382623] [drm] nouveau 0000:01:00.0: 1: 0x00000100: type 0x00 idx 1 tag 0xff [ 0.382626] [drm] nouveau 0000:01:00.0: 2: 0x00001231: type 0x31 idx 2 tag 0x07 [ 0.382628] [drm] nouveau 0000:01:00.0: Raw DCB entry 0: 01000323 00010034 [ 0.382630] [drm] nouveau 0000:01:00.0: Raw DCB entry 1: 02811300 00000028 [ 0.382632] [drm] nouveau 0000:01:00.0: Raw DCB entry 2: 02822312 00010030 [ 0.382633] [drm] nouveau 0000:01:00.0: Raw DCB entry 3: 0000000e 00000000 [ 0.382641] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xDEBB [ 0.420125] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xE208 [ 0.453350] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xEC55 [ 0.453358] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xED47 [ 0.460091] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xEF7A [ 0.460093] [drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xEFDF [ 0.483353] [drm] nouveau 0000:01:00.0: 0xEFDF: Condition still not met after 20ms, skipping following opcodes [ 0.483360] [drm] nouveau 0000:01:00.0: 0xD01A: parsing output script 0 [ 0.483362] [drm] nouveau 0000:01:00.0: 0xD190: parsing output script 0 [ 0.600743] [TTM] Zone kernel: Available graphics memory: 1993568 kiB. [ 0.600755] [drm] nouveau 0000:01:00.0: 256 MiB VRAM [ 0.632525] [drm] nouveau 0000:01:00.0: 512 MiB GART (aperture) [ 0.632531] mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining [ 0.632541] nouveau 0000:01:00.0: firmware: using built-in firmware nouveau/nv84.ctxprog [ 0.632545] nouveau 0000:01:00.0: firmware: using built-in firmware nouveau/nv84.ctxvals [ 0.632801] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1 [ 0.640758] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 1 [ 0.641523] [drm] nouveau 0000:01:00.0: Detected a LVDS output [ 0.641527] [drm] nouveau 0000:01:00.0: Detected a DAC output [ 0.641529] [drm] nouveau 0000:01:00.0: Detected a TMDS output [ 0.641531] [drm] nouveau 0000:01:00.0: Detected a LVDS connector [ 0.741133] [drm] nouveau 0000:01:00.0: Detected a VGA connector [ 0.741222] [drm] nouveau 0000:01:00.0: Detected a DVI-D connector [ 2.173573] [drm] nouveau 0000:01:00.0: allocated 1920x1200 fb: 0x40250000, bo ffff88013b9c5800 [ 2.175406] [drm] nouveau 0000:01:00.0: 0xD01E: parsing output script 1 [ 2.175431] [drm] nouveau 0000:01:00.0: 0xCEC7: parsing clock script 0 [ 2.175437] BUG: scheduling while atomic: nouveau/0/753/0x00000002 [ 2.175439] Modules linked in: [ 2.175442] Pid: 753, comm: nouveau/0 Not tainted 2.6.33-rc8-prerelease #27 [ 2.175443] Call Trace: [ 2.175451] [<ffffffff815dcdea>] ? schedule+0x86a/0x880 [ 2.175454] [<ffffffff8120a420>] ? vsnprintf+0xe0/0x9a0 [ 2.175456] [<ffffffff815dd18c>] ? schedule_timeout+0x15c/0x250 [ 2.175460] [<ffffffff81068570>] ? process_timeout+0x0/0x10 [ 2.175462] [<ffffffff81069068>] ? msleep+0x18/0x30 [ 2.175466] [<ffffffff812d48d1>] ? init_time+0x51/0x90 [ 2.175468] [<ffffffff812d3ffb>] ? parse_init_table+0xcb/0x1a0 [ 2.175470] [<ffffffff812d424a>] ? init_sub_direct+0x4a/0xd0 [ 2.175472] [<ffffffff812d3ffb>] ? parse_init_table+0xcb/0x1a0 [ 2.175474] [<ffffffff812d496f>] ? nouveau_bios_run_init_table+0x5f/0xa0 [ 2.175476] [<ffffffff812d4c0c>] ? nouveau_bios_run_display_table+0x25c/0x500 [ 2.175480] [<ffffffff812fd220>] ? nv50_display_irq_handler_bh+0x0/0x410 [ 2.175483] [<ffffffff812fd4cc>] ? nv50_display_irq_handler_bh+0x2ac/0x410 [ 2.175485] [<ffffffff812fd220>] ? nv50_display_irq_handler_bh+0x0/0x410 [ 2.175487] [<ffffffff8107047b>] ? worker_thread+0x16b/0x250 [ 2.175490] [<ffffffff81074240>] ? autoremove_wake_function+0x0/0x30 [ 2.175492] [<ffffffff81070310>] ? worker_thread+0x0/0x250 [ 2.175494] [<ffffffff81070310>] ? worker_thread+0x0/0x250 [ 2.175496] [<ffffffff81073dbe>] ? kthread+0x8e/0xa0 [ 2.175499] [<ffffffff81027554>] ? kernel_thread_helper+0x4/0x10 [ 2.175501] [<ffffffff81073d30>] ? kthread+0x0/0xa0 [ 2.175503] [<ffffffff81027550>] ? kernel_thread_helper+0x0/0x10 [ 2.182407] Console: switching to colour frame buffer device 240x75 [ 2.186632] fb0: nouveaufb frame buffer device [ 2.186633] registered panic notifier [ 2.186636] [drm] Initialized nouveau 0.0.15 20090420 for 0000:01:00.0 on minor 0 ... |
Thanks for helping keep SourceForge clean.
X