Re: DRM code reorganization

2004-08-03 Thread Eric Anholt
On Mon, 2004-08-02 at 11:57, Dave Jones wrote: I don't maintain upstream DRM, but I have a fair amount of responsibility regarding the Fedora kernel, and I'll state publically that looking at bugs in drivers/char/drm is right up there on my list of things I'd rather not do after lunch.

Re: DRM code reorganization

2004-08-03 Thread Keith Whitwell
Ian Romanick wrote: I think this is the right place to start. A couple of these look easier to get rid of than others. __HAVE_MTRR and __HAVE_AGP are enabled in every driver except ffb. It should be easy enough to get rid of them. It looks like __HAVE_RELEASE, __HAVE_DMA_READY,

Re: DRM code reorganization

2004-08-03 Thread Ian Romanick
Keith Whitwell wrote: We've actually managed to do a fair bit of cleanup already - if you look at the gamma driver, there's a lot of stuff in there which used to be shared but ifdef'ed out between all the drivers. The __HAVE_MULTIPLE_DMA_QUEUES macro is a remnant of this, but I think you'll

Re: DRM code reorganization

2004-08-03 Thread Keith Whitwell
Ian Romanick wrote: Keith Whitwell wrote: We've actually managed to do a fair bit of cleanup already - if you look at the gamma driver, there's a lot of stuff in there which used to be shared but ifdef'ed out between all the drivers. The __HAVE_MULTIPLE_DMA_QUEUES macro is a remnant of this,

Re: DRM code reorganization

2004-08-02 Thread Ian Romanick
Jon Smirl wrote: 4) DRM code reorganization. There were several requests to reorganize DRM to more closely follow the Linux kernel guidelines. This reorganization should occur before new features are added. What should be the model for reorganizing DRM? An obvious change is eliminate the naming

Re: DRM code reorganization

2004-08-02 Thread Keith Whitwell
ian: what about splitting the current memory management code into a module that can be swapped for your new version? AFAIK, the only drivers that have any sort of in-kernel memory manager are the radeon (only used by the R200 driver) and i830. That memory manager only exists to support an

Re: DRM code reorganization

2004-08-02 Thread Dave Jones
On Mon, Aug 02, 2004 at 11:02:43AM -0700, Ian Romanick wrote: This would be *very* non-trivial to do. Doing the DRM like this has come up probably a dozen times (or more) over the last 3 years. Which should ring alarm bells that something might not be quite right. The problem is that

Re: DRM code reorganization

2004-08-02 Thread Alan Cox
On Llu, 2004-08-02 at 19:57, Dave Jones wrote: The problem is that each driver has different needs based on hardware functionality. How does this differ from any other subsystem that supports cards with features that may not be present in another model ? Other subsystems have dealt

Re: DRM code reorganization

2004-08-02 Thread Ian Romanick
Dave Jones wrote: On Mon, Aug 02, 2004 at 11:02:43AM -0700, Ian Romanick wrote: This would be *very* non-trivial to do. Doing the DRM like this has come up probably a dozen times (or more) over the last 3 years. Which should ring alarm bells that something might not be quite right. And that

Re: DRM code reorganization

2004-08-02 Thread Jon Smirl
We are really short handed for kernel level DRM developers; most 3D developers work in user space. The main person that wrote it, Gareth Hughes, doesn't seem to work on it any more. Right now there are three to four, non-paid people working part-time on DRM. How about you kernel developers

Re: DRM code reorganization

2004-08-02 Thread Dave Jones
On Mon, Aug 02, 2004 at 01:11:26PM -0700, Ian Romanick wrote: This would be *very* non-trivial to do. Doing the DRM like this has come up probably a dozen times (or more) over the last 3 years. Which should ring alarm bells that something might not be quite right. And that it hasn't

Re: DRM code reorganization

2004-08-02 Thread Michel Dänzer
On Mon, 2004-08-02 at 22:09 +0100, Dave Jones wrote: If subsequent DRI tree - kernel merges back out any cleanup work, it's definitly going to be a waste of time even trying. That can easily be avoided by doing the cleanup the right way in the first place, i.e. in the DRI tree... --

Re: DRM code reorganization

2004-08-02 Thread Jon Smirl
--- Dave Jones [EMAIL PROTECTED] wrote: Another possibility of course is that the BSD Linux kernel side bits go their separate ways. How active is the kernel side of the BSD world ? I'll probably get flamed to death for suggesting this, but why not? What about leaving BSD working with the

Re: DRM code reorganization

2004-08-02 Thread Dave Airlie
If this is something that we really want to pursue, someone needs to dig in and figure out: 1. How much / which code can be trivially shared? 2. How much / which code can be shared with very little work? 3. How much / which code would we rather get a root-canal than try to make shared?

Re: DRM code reorganization

2004-08-02 Thread Ian Romanick
Dave Jones wrote: On Mon, Aug 02, 2004 at 01:11:26PM -0700, Ian Romanick wrote: This would be *very* non-trivial to do. Doing the DRM like this has come up probably a dozen times (or more) over the last 3 years. Which should ring alarm bells that something might not be quite right.

Re: DRM code reorganization

2004-08-02 Thread Alan Cox
On Llu, 2004-08-02 at 22:09, Dave Jones wrote: Whip me, beat me, make me clean up drivers/char/drm 8-) Im sure that can be arranged by someone. Another possibility of course is that the BSD Linux kernel side bits go their seperate ways. How active is the kernel side of the BSD world ?