Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Wed, Mar 18, 2009 at 09:08:09PM -0700, Greg KH wrote: > Hi, > > Here's 5 patches that add the Intel Poulsbo/Morrestown DRM driver to the > kernel tree. Ok, in reviewing the issues that Alan rightfully brought up, I'm going to "retract" these patches right now and go back and try to only get the 2d stuff up and working properly. Due to a vacation on my side in the next few weeks, this might take a while, I'll come back when I have something that is working and doesn't support the binary blob mess. thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
Greg KH wrote: > On Fri, Mar 20, 2009 at 03:00:32PM +, Alan Cox wrote: > By the same logic, would you support including the proprietary NVIDIA driver while we wait for Nouveau to catch up? >>> The license of the NVIDIA driver does not allow that to even be a >>> possibility. >>> >> I'm not convinced this is any different. If you accept the 3D changes you >> step into a dangerous world of estoppel and since it has many >> rightsholders also the wonderful world of contributory infringement. It >> really really needs lawyers to look into it. >> > > I would hope that Intel's lawyers would have done such a thing before > releasing the kernel and xorg code under the licenses that they did :) > > >> Now the other way to do it that might be more productive and simpler >> would be to rip all the 3D crap out of that driver and just include the >> minimum needed 2D bits for the open source X driver. Makes the code >> smaller and cleaner, avoids an legal questions and lets people get on >> with real work. >> > > Hm, that sounds fine to me. > > Does that mean that all of these drm patches that I posted are _only_ > needed for the 3d portions of the driver? If I rip out the portions of > the psb kernel driver that need these changes, do I end up with an > working 2d driver as well? Richard and Thomas, any thoughts here? > > thanks, > > greg k-h > > Greg, Let's not forget the video stuff. I'm not sure about the status of that. But all the other patches are needed for 2D functionality and kernel modesetting. If you want to strip 3D you can strip. psb_schedule.[ch] - The 3D scheduler. psb_xhw.c - The interface to the binary X server module. psb_scene.c - The 3D scene tracker. and anything that appears unused after that. This means you lose Render acceleration and textured video and downscaling in the X server as well, although accelerated rotation should still work, since it uses the 2D engine. I think the video acceleration sits in psb_msvdx.c psb_msvdxinit.c lnc_topaz.c lnc_topazinit.c /Thomas -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Fri, Mar 20, 2009 at 03:00:32PM +, Alan Cox wrote: > > > By the same logic, would you support including the proprietary NVIDIA > > > driver while we wait for Nouveau to catch up? > > > > The license of the NVIDIA driver does not allow that to even be a > > possibility. > > I'm not convinced this is any different. If you accept the 3D changes you > step into a dangerous world of estoppel and since it has many > rightsholders also the wonderful world of contributory infringement. It > really really needs lawyers to look into it. I would hope that Intel's lawyers would have done such a thing before releasing the kernel and xorg code under the licenses that they did :) > Now the other way to do it that might be more productive and simpler > would be to rip all the 3D crap out of that driver and just include the > minimum needed 2D bits for the open source X driver. Makes the code > smaller and cleaner, avoids an legal questions and lets people get on > with real work. Hm, that sounds fine to me. Does that mean that all of these drm patches that I posted are _only_ needed for the 3d portions of the driver? If I rip out the portions of the psb kernel driver that need these changes, do I end up with an working 2d driver as well? Richard and Thomas, any thoughts here? thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Fri, Mar 20, 2009 at 05:08:23PM +1100, Daniel Stone wrote: > Greg, > > On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote: > > On Thu, Mar 19, 2009 at 12:03:09PM -0400, Sindhudweep Sarkar wrote: > > > TI-OMAP 3xxx and a couple of other arm processors use similar SGX-5xx > > > graphics cores. IIRC arm is often little endian so perhaps a unified > > > driver would be easier in the long term. > > > > Long term lots of things are good. > > > > But how do I get my laptop that I currently have right now up and > > running properly with linux in a better-than-800x600-framebuffer mode? > > > > That's why I need/want this driver now, there are hundreds of thousands > > of these types of laptops in the pipeline to users and I want them to > > run Linux, not be forced to run some other operating system... > > By the same logic, would you support including the proprietary NVIDIA > driver while we wait for Nouveau to catch up? The license of the NVIDIA driver does not allow that to even be a possibility. thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
> > By the same logic, would you support including the proprietary NVIDIA > > driver while we wait for Nouveau to catch up? > > The license of the NVIDIA driver does not allow that to even be a > possibility. I'm not convinced this is any different. If you accept the 3D changes you step into a dangerous world of estoppel and since it has many rightsholders also the wonderful world of contributory infringement. It really really needs lawyers to look into it. Now the other way to do it that might be more productive and simpler would be to rip all the 3D crap out of that driver and just include the minimum needed 2D bits for the open source X driver. Makes the code smaller and cleaner, avoids an legal questions and lets people get on with real work. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 10:39:03AM +, Alan Cox wrote: > > The non-existence of an open-source 3D implementation doesn't really > > alter that situation. > > I think it does to an extent With an opensource 2d solution it does? > > However, if there's a policy issue about adding Linux kernel support for > > closed-source user-space drivers, I think it helps to be explicit about > > that. > > Actually its a lawyer question not just policy. If the two parts being put > together are tightly dependant on each other and in fact form a single > work which it seems could reasonably be the case in this situation then > if one half is GPL the other must also be so. I'm not going to disagree with that, which would force the 3d portions open. At the moment I'm more worried about just getting 2d to work at all. I was going to wait for the "rewrite" to worry about 3d stuff, as it will be done properly that way. thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 11:14:35AM +0100, Thomas Hellström wrote: >> First off, the non-staging patches need more complete changelog entries, >> a bit of meaning goes a long way. I'll ack them if they are documented and >> make sense. The unlocked ioctl hook makes sense to me at least! >> > > For the non-staging patches, (which also sit in the modesetting-newttm > tree), I can add some more elaborate comments. However I think all of > them are targeted to support functionality for TTM, so unless the TTM > code goes into staging or mainstream, there is little point in merging > them to core drm before other drivers find them useful. > > Although I see the patch adding TTM is including some backwards > compatibility defines (In particular the PAT compat stuff) that needs > to be stripped. Great, care to respin it and send it to me? thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 12:02:54PM -0700, Greg KH wrote: > On Thu, Mar 19, 2009 at 06:53:38PM +, Matthew Garrett wrote: > > On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote: > > > > > But how do I get my laptop that I currently have right now up and > > > running properly with linux in a better-than-800x600-framebuffer mode? > > > > You don't, because there's no working X driver. > > Um, no, I have one right here, seems to work ok. Richard pointed out > the public git tree for it. With current X? If that's been fixed up recently then it's a definite improvement, but last I checked it only built against old X servers. -- Matthew Garrett | mj...@srcf.ucam.org -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 04:48:54PM +1000, Dave Airlie wrote: > On Thu, Mar 19, 2009 at 2:08 PM, Greg KH wrote: > > Hi, > > > > Here's 5 patches that add the Intel Poulsbo/Morrestown DRM driver to the > > kernel tree. > > > > There are 4 patches that make changes to the DRM core, and one patch > > that adds the DRM driver itself. The driver is added to the > > drivers/staging/ directory because it is not the "final" driver that > > Intel wishes to support over time. The userspace api is going to > > change, and work is currently underway to hook up properly with the > > memory management system. > > > > > However this work is going to take a while, and in the meantime, users > > want to run Linux on this kind of hardware. I'd really like to add the > > driver to the staging tree, but it needs these core DRM changes in order > > to get it to work properly. > > > > Originally I had a patch that basically duplicated the existing DRM > > core, and embedded it with these changes and the PSB driver together > > into one big mess of a kernel module. But Richard convinced me that > > this wasn't the "nicest" thing to do, and he did work on the PSB code > > and dug out these older DRM patches. > > > > The only thing that looks a bit "odd" to me is the unlocked ioctl patch, > > Thomas, is that thing really correct? > > > > David, I'd be glad to take the DRM changes through the staging tree, but > > only if you ack them. > > First off, the non-staging patches need more complete changelog entries, > a bit of meaning goes a long way. I'll ack them if they are documented and > make sense. The unlocked ioctl hook makes sense to me at least! Heh, that one doesn't make sense to me as it doesn't seem to change any locking issues :) I'll write up better changelog comments based on other responses in this thread. > Now the non-core DRM driver comes with some caveats no one mentioned, > only the userspace 2D is open, no userspace 3D is available and I've no idea > if > one is forthcoming. Now I don't know enough about the Poulsbo to say this > drm implementation is secure and can't DMA over my password file. > > There is no upstream X.org driver available for this yet, Ubuntu > shipped something but really we should be at least seeing X.org and > Mesa commitments from Intel to supporting this code in the future > before we go shipping it all in the kernel. The xorg driver is public, as has been pointed out. As for the legality of the 3d binary blob, I really have no idea, and for now, I really don't care, I just want basic 2d to work properly on my hardware. > Staging something with a very broken userspace API is going to be an > nightmare, That's exactly what staging is for :) Seriously, stuff in drivers/staging has horrible userspace api issues, and has no guarantee to work properly at all in future kernel versions. That's why we are using the staging tree, it lets users have a common place to get the latest code to get their hardware working, and lets developers work together in one place. See my lkml post yesterday about staging if you have other questions about it. > So really I'm NAKing this from ever entering the mainline in its > current form, without a supporting roadmap and plans for the userspace > bits. staging isn't really "mainline" so much as it is a place to get things working. If you want, I'll respin the drm changes and resubmit them. If you aren't going to want to accept those drm changes, that's fine, and I have no problem with that. In that case, I'll just "embed" a private copy of the drm core in the psb kernel driver in staging, much like we have done many times already with wireless drivers. Yes, it's not the nicest or prettiest thing at all, but it lets people use their hardware and is a hell of a lot better than burrying this stuff in random git trees around the world in ways that no one else can figure out how to get working (like Ubuntu has already done...) thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 09:40:08PM +0100, Thomas Hellström wrote: > Greg KH wrote: >> On Thu, Mar 19, 2009 at 11:14:35AM +0100, Thomas Hellström wrote: >> First off, the non-staging patches need more complete changelog entries, a bit of meaning goes a long way. I'll ack them if they are documented and make sense. The unlocked ioctl hook makes sense to me at least! >>> For the non-staging patches, (which also sit in the modesetting-newttm >>> tree), I can add some more elaborate comments. However I think all of >>> them are targeted to support functionality for TTM, so unless the TTM >>> code goes into staging or mainstream, there is little point in merging >>> them to core drm before other drivers find them useful. >>> >>> Although I see the patch adding TTM is including some backwards >>> compatibility defines (In particular the PAT compat stuff) that needs >>> to be stripped. >>> >> >> Great, care to respin it and send it to me? >> > Greg, > A clean TTM patch was sent to Intel with the other patches. > I'm not sure why it got lost along the way? As there seems to be an unknown number of people in the "intel chain" that resulted in me finally getting these patches, I don't hold out much hope that I'm going to be able to get more than what I already got from them :( So, any chance you could just resend it? I'll be glad to trade it for a beer at the next conference :) thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 02:11:18PM -0400, Sindhudweep Sarkar wrote: > Of course real support for poulsbo is really important and desirable > since netbooks make such a huge percentage of computer sales these > days. I'm guessing, however, that the number of > embedded/mobile/appliance devices that use or will use the SGX5xx is > much larger than even the plethora of netbooks being pumped out. If > more hardware support can be gained for a little extra burden why not > go for it? I would argue that a unified driver stack would actually > have less maintenance cost since common bugs could be killed. Even > ignoring all the arm devices that will use that graphics core, what > about intel's own use of the SGX 535 elsewhere? Does this "poulsbo" > driver support the intel CE3100 processors? > > > I think i'm really apprehensive about device specific one-offs. Of > course a mainline driver upstream is an important step to prevent that > but without a roadmap it only seems marginally better. Staging is all aobut "device specific one-offs". the code is then in a common area where everyone can work to fix it up properly. I don't want to burry this work again in random git trees that no one has any clue how to put together, like has already been done in the past. thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote: > But how do I get my laptop that I currently have right now up and > running properly with linux in a better-than-800x600-framebuffer mode? You don't, because there's no working X driver. -- Matthew Garrett | mj...@srcf.ucam.org -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
> Nokia's written and open-sourced some related code for DRM. > > My university is paying me to work on an ARM-based SoC handheld with an > SGX core, and I might be more into this later. (Y'know, once the device > is actually out the door.) > > ~ C. > Could you point me to the aforementioned open-sourced drm code? -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
Greg, On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote: > On Thu, Mar 19, 2009 at 12:03:09PM -0400, Sindhudweep Sarkar wrote: > > TI-OMAP 3xxx and a couple of other arm processors use similar SGX-5xx > > graphics cores. IIRC arm is often little endian so perhaps a unified > > driver would be easier in the long term. > > Long term lots of things are good. > > But how do I get my laptop that I currently have right now up and > running properly with linux in a better-than-800x600-framebuffer mode? > > That's why I need/want this driver now, there are hundreds of thousands > of these types of laptops in the pipeline to users and I want them to > run Linux, not be forced to run some other operating system... By the same logic, would you support including the proprietary NVIDIA driver while we wait for Nouveau to catch up? Cheers, Daniel signature.asc Description: Digital signature -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
Greg KH wrote: > On Thu, Mar 19, 2009 at 11:14:35AM +0100, Thomas Hellström wrote: > >>> First off, the non-staging patches need more complete changelog entries, >>> a bit of meaning goes a long way. I'll ack them if they are documented and >>> make sense. The unlocked ioctl hook makes sense to me at least! >>> >>> >> For the non-staging patches, (which also sit in the modesetting-newttm >> tree), I can add some more elaborate comments. However I think all of >> them are targeted to support functionality for TTM, so unless the TTM >> code goes into staging or mainstream, there is little point in merging >> them to core drm before other drivers find them useful. >> >> Although I see the patch adding TTM is including some backwards >> compatibility defines (In particular the PAT compat stuff) that needs >> to be stripped. >> > > Great, care to respin it and send it to me? > > thanks, > > greg k-h > Greg, A clean TTM patch was sent to Intel with the other patches. I'm not sure why it got lost along the way? /Thomas -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
Richard Purdie wrote: > On Thu, 2009-03-19 at 12:03 -0400, Sindhudweep Sarkar wrote: >> This might be the opinion of a completely non educated end user but it >> seems that an intel specific drm and other bits (xorg, mesa) would be >> somewhat of a maintenance waste. >> >> TI-OMAP 3xxx and a couple of other arm processors use similar SGX-5xx >> graphics cores. IIRC arm is often little endian so perhaps a unified >> driver would be easier in the long term. > > Long term a unified driver would be very nice to have and nobody > disagrees with that. Things don't happen overnight and you have to take > smaller steps to get there. This proposal is one step on a road that may > lead to a driver for the TI part too. It will need someone in the ARM > community to step up and write the ARM specific bits. Nokia's written and open-sourced some related code for DRM. My university is paying me to work on an ARM-based SoC handheld with an SGX core, and I might be more into this later. (Y'know, once the device is actually out the door.) ~ C. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 06:53:38PM +, Matthew Garrett wrote: > On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote: > > > But how do I get my laptop that I currently have right now up and > > running properly with linux in a better-than-800x600-framebuffer mode? > > You don't, because there's no working X driver. Um, no, I have one right here, seems to work ok. Richard pointed out the public git tree for it. Yes, there's no excellerated 3d without the binary xorg "blob", but I really don't need that right now. thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 07:05:30PM +, Matthew Garrett wrote: > On Thu, Mar 19, 2009 at 12:02:54PM -0700, Greg KH wrote: > > On Thu, Mar 19, 2009 at 06:53:38PM +, Matthew Garrett wrote: > > > On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote: > > > > > > > But how do I get my laptop that I currently have right now up and > > > > running properly with linux in a better-than-800x600-framebuffer mode? > > > > > > You don't, because there's no working X driver. > > > > Um, no, I have one right here, seems to work ok. Richard pointed out > > the public git tree for it. > > With current X? If that's been fixed up recently then it's a definite > improvement, but last I checked it only built against old X servers. It currently only builds with new X servers, which turned out to be a problem trying to get it to work on an openSUSE 11.1 machine, which uses an older xserver, but that's a distro issue, not an upstream issue... thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
Of course real support for poulsbo is really important and desirable since netbooks make such a huge percentage of computer sales these days. I'm guessing, however, that the number of embedded/mobile/appliance devices that use or will use the SGX5xx is much larger than even the plethora of netbooks being pumped out. If more hardware support can be gained for a little extra burden why not go for it? I would argue that a unified driver stack would actually have less maintenance cost since common bugs could be killed. Even ignoring all the arm devices that will use that graphics core, what about intel's own use of the SGX 535 elsewhere? Does this "poulsbo" driver support the intel CE3100 processors? I think i'm really apprehensive about device specific one-offs. Of course a mainline driver upstream is an important step to prevent that but without a roadmap it only seems marginally better. Best, Sindhudweep On Thu, Mar 19, 2009 at 12:27 PM, Greg KH wrote: > On Thu, Mar 19, 2009 at 12:03:09PM -0400, Sindhudweep Sarkar wrote: >> This might be the opinion of a completely non educated end user but it >> seems that an intel specific drm and other bits (xorg, mesa) would be >> somewhat of a maintenance waste. > > What do you mean by this? > >> TI-OMAP 3xxx and a couple of other arm processors use similar SGX-5xx >> graphics cores. IIRC arm is often little endian so perhaps a unified >> driver would be easier in the long term. > > Long term lots of things are good. > > But how do I get my laptop that I currently have right now up and > running properly with linux in a better-than-800x600-framebuffer mode? > > That's why I need/want this driver now, there are hundreds of thousands > of these types of laptops in the pipeline to users and I want them to > run Linux, not be forced to run some other operating system... > > thanks, > > greg k-h > -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, 2009-03-19 at 12:03 -0400, Sindhudweep Sarkar wrote: > This might be the opinion of a completely non educated end user but it > seems that an intel specific drm and other bits (xorg, mesa) would be > somewhat of a maintenance waste. > > TI-OMAP 3xxx and a couple of other arm processors use similar SGX-5xx > graphics cores. IIRC arm is often little endian so perhaps a unified > driver would be easier in the long term. Long term a unified driver would be very nice to have and nobody disagrees with that. Things don't happen overnight and you have to take smaller steps to get there. This proposal is one step on a road that may lead to a driver for the TI part too. It will need someone in the ARM community to step up and write the ARM specific bits. Cheers, Richard -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 12:03:09PM -0400, Sindhudweep Sarkar wrote: > This might be the opinion of a completely non educated end user but it > seems that an intel specific drm and other bits (xorg, mesa) would be > somewhat of a maintenance waste. What do you mean by this? > TI-OMAP 3xxx and a couple of other arm processors use similar SGX-5xx > graphics cores. IIRC arm is often little endian so perhaps a unified > driver would be easier in the long term. Long term lots of things are good. But how do I get my laptop that I currently have right now up and running properly with linux in a better-than-800x600-framebuffer mode? That's why I need/want this driver now, there are hundreds of thousands of these types of laptops in the pipeline to users and I want them to run Linux, not be forced to run some other operating system... thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
This might be the opinion of a completely non educated end user but it seems that an intel specific drm and other bits (xorg, mesa) would be somewhat of a maintenance waste. TI-OMAP 3xxx and a couple of other arm processors use similar SGX-5xx graphics cores. IIRC arm is often little endian so perhaps a unified driver would be easier in the long term. On Thu, Mar 19, 2009 at 12:08 AM, Greg KH wrote: > Hi, > > Here's 5 patches that add the Intel Poulsbo/Morrestown DRM driver to the > kernel tree. > > There are 4 patches that make changes to the DRM core, and one patch > that adds the DRM driver itself. The driver is added to the > drivers/staging/ directory because it is not the "final" driver that > Intel wishes to support over time. The userspace api is going to > change, and work is currently underway to hook up properly with the > memory management system. > > However this work is going to take a while, and in the meantime, users > want to run Linux on this kind of hardware. I'd really like to add the > driver to the staging tree, but it needs these core DRM changes in order > to get it to work properly. > > Originally I had a patch that basically duplicated the existing DRM > core, and embedded it with these changes and the PSB driver together > into one big mess of a kernel module. But Richard convinced me that > this wasn't the "nicest" thing to do, and he did work on the PSB code > and dug out these older DRM patches. > > The only thing that looks a bit "odd" to me is the unlocked ioctl patch, > Thomas, is that thing really correct? > > David, I'd be glad to take the DRM changes through the staging tree, but > only if you ack them. > > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
Hi, On Thu, 2009-03-19 at 16:48 +1000, Dave Airlie wrote: > First off, the non-staging patches need more complete changelog entries, > a bit of meaning goes a long way. I'll ack them if they are documented and > make sense. The unlocked ioctl hook makes sense to me at least! > > Now the non-core DRM driver comes with some caveats no one mentioned, > only the userspace 2D is open, no userspace 3D is available and I've no idea > if > one is forthcoming. Now I don't know enough about the Poulsbo to say this > drm implementation is secure and can't DMA over my password file. I think Thomas has covered these things and between us, we can improve the patch series. > There is no upstream X.org driver available for this yet, Ubuntu > shipped something > but really we should be at least seeing X.org and Mesa commitments from Intel > to supporting this code in the future before we go shipping it all in > the kernel. An older version of the X.org driver has been available (with various urls) at http://git.moblin.org/cgit.cgi/deprecated/xf86-video-psb/ for a while. I'm working on getting this updated and that should happen soon. I'm also working on getting the binary bits for 3D support publicly available somewhere but these are not open source and unlikely to be any time soon. We know this sucks, we're working on it but thats all I can really say. As Greg said, we don't envisage this driver being the final solution. There is hardware out there, running Linux which needs any driver rather than no driver now. Having a standard implementation that everyone uses has to be preferable to everyone rolling their own modified version of it. For 2D, the driver is open and people can chose to use the 3D binaries or not. This would seem to fit the staging tree's mandate where this driver could live until things get sorted properly. Does this ease some of your concerns? I don't claim this is an ideal situation but we're all trying to make the best of what we've got... Cheers, Richard -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
> The non-existence of an open-source 3D implementation doesn't really > alter that situation. I think it does to an extent > > However, if there's a policy issue about adding Linux kernel support for > closed-source user-space drivers, I think it helps to be explicit about > that. Actually its a lawyer question not just policy. If the two parts being put together are tightly dependant on each other and in fact form a single work which it seems could reasonably be the case in this situation then if one half is GPL the other must also be so. There is also policy on this, I refer you back to the Intel wireless and binary management daemon discussions. I likewise refer you to some of the input device discussions related to USB HID and devices where vendors wanted us to exclude their device in favour of proprietary libusb drivers. Alan -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
Dave and Greg, Some quick comments below. Dave Airlie wrote: > On Thu, Mar 19, 2009 at 2:08 PM, Greg KH wrote: > >> Hi, >> >> Here's 5 patches that add the Intel Poulsbo/Morrestown DRM driver to the >> kernel tree. >> >> There are 4 patches that make changes to the DRM core, and one patch >> that adds the DRM driver itself. The driver is added to the >> drivers/staging/ directory because it is not the "final" driver that >> Intel wishes to support over time. The userspace api is going to >> change, and work is currently underway to hook up properly with the >> memory management system. >> > > >> However this work is going to take a while, and in the meantime, users >> want to run Linux on this kind of hardware. I'd really like to add the >> driver to the staging tree, but it needs these core DRM changes in order >> to get it to work properly. >> >> Originally I had a patch that basically duplicated the existing DRM >> core, and embedded it with these changes and the PSB driver together >> into one big mess of a kernel module. But Richard convinced me that >> this wasn't the "nicest" thing to do, and he did work on the PSB code >> and dug out these older DRM patches. >> >> The only thing that looks a bit "odd" to me is the unlocked ioctl patch, >> Thomas, is that thing really correct? >> >> David, I'd be glad to take the DRM changes through the staging tree, but >> only if you ack them. >> > > First off, the non-staging patches need more complete changelog entries, > a bit of meaning goes a long way. I'll ack them if they are documented and > make sense. The unlocked ioctl hook makes sense to me at least! > For the non-staging patches, (which also sit in the modesetting-newttm tree), I can add some more elaborate comments. However I think all of them are targeted to support functionality for TTM, so unless the TTM code goes into staging or mainstream, there is little point in merging them to core drm before other drivers find them useful. Although I see the patch adding TTM is including some backwards compatibility defines (In particular the PAT compat stuff) that needs to be stripped. > Now the non-core DRM driver comes with some caveats no one mentioned, > only the userspace 2D is open, no userspace 3D is available and I've no idea > if > one is forthcoming. Now I don't know enough about the Poulsbo to say this > drm implementation is secure and can't DMA over my password file. > > The GPU in Poulsbo / Morestown can only access memory through a multi-context 4GB two-level page-table, and the implementation of that is open in psb_mmu.c. The VDC is accessing memory through a traditional Intel GTT: psb_gtt.c The registers used to set up the page table are blocked from user-space access. Any registers used to fire GPU assembly code with privileges to change those registers are also blocked. So security-wise there is nothing worse with this device than with other devices without full open documentation. And AFAICT it's more secure than some drivers _with_ full open documentation. The non-existence of an open-source 3D implementation doesn't really alter that situation. However, if there's a policy issue about adding Linux kernel support for closed-source user-space drivers, I think it helps to be explicit about that. > There is no upstream X.org driver available for this yet, Ubuntu > shipped something > but really we should be at least seeing X.org and Mesa commitments from Intel > to supporting this code in the future before we go shipping it all in > the kernel. > > ... > Staging something with a very broken userspace API is going to be an > nightmare, > its fine if my audio doesn't work, but when X fails to start people > are left in a lot worse > place, personally I would never stage any driver that can break the > users userspace > this badly when we finally do get a version we want to upstream > properly. GPU drivers > are not just a kernel bit, they are not like a network card or sound > driver, where the > userspace API is mostly defined or a filesystem where we have POSIX. > > I can't really comment on this since I have no knowledge about the upcoming interface changes. Thanks, Thomas > So really I'm NAKing this from ever entering the mainline in its > current form, without > a supporting roadmap and plans for the userspace bits. > > Dave. > > >> thanks, >> >> greg k-h >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> >> > > -- > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based develop
[patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
Hi, Here's 5 patches that add the Intel Poulsbo/Morrestown DRM driver to the kernel tree. There are 4 patches that make changes to the DRM core, and one patch that adds the DRM driver itself. The driver is added to the drivers/staging/ directory because it is not the "final" driver that Intel wishes to support over time. The userspace api is going to change, and work is currently underway to hook up properly with the memory management system. However this work is going to take a while, and in the meantime, users want to run Linux on this kind of hardware. I'd really like to add the driver to the staging tree, but it needs these core DRM changes in order to get it to work properly. Originally I had a patch that basically duplicated the existing DRM core, and embedded it with these changes and the PSB driver together into one big mess of a kernel module. But Richard convinced me that this wasn't the "nicest" thing to do, and he did work on the PSB code and dug out these older DRM patches. The only thing that looks a bit "odd" to me is the unlocked ioctl patch, Thomas, is that thing really correct? David, I'd be glad to take the DRM changes through the staging tree, but only if you ack them. thanks, greg k-h -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
On Thu, Mar 19, 2009 at 2:08 PM, Greg KH wrote: > Hi, > > Here's 5 patches that add the Intel Poulsbo/Morrestown DRM driver to the > kernel tree. > > There are 4 patches that make changes to the DRM core, and one patch > that adds the DRM driver itself. The driver is added to the > drivers/staging/ directory because it is not the "final" driver that > Intel wishes to support over time. The userspace api is going to > change, and work is currently underway to hook up properly with the > memory management system. > > However this work is going to take a while, and in the meantime, users > want to run Linux on this kind of hardware. I'd really like to add the > driver to the staging tree, but it needs these core DRM changes in order > to get it to work properly. > > Originally I had a patch that basically duplicated the existing DRM > core, and embedded it with these changes and the PSB driver together > into one big mess of a kernel module. But Richard convinced me that > this wasn't the "nicest" thing to do, and he did work on the PSB code > and dug out these older DRM patches. > > The only thing that looks a bit "odd" to me is the unlocked ioctl patch, > Thomas, is that thing really correct? > > David, I'd be glad to take the DRM changes through the staging tree, but > only if you ack them. First off, the non-staging patches need more complete changelog entries, a bit of meaning goes a long way. I'll ack them if they are documented and make sense. The unlocked ioctl hook makes sense to me at least! Now the non-core DRM driver comes with some caveats no one mentioned, only the userspace 2D is open, no userspace 3D is available and I've no idea if one is forthcoming. Now I don't know enough about the Poulsbo to say this drm implementation is secure and can't DMA over my password file. There is no upstream X.org driver available for this yet, Ubuntu shipped something but really we should be at least seeing X.org and Mesa commitments from Intel to supporting this code in the future before we go shipping it all in the kernel. Staging something with a very broken userspace API is going to be an nightmare, its fine if my audio doesn't work, but when X fails to start people are left in a lot worse place, personally I would never stage any driver that can break the users userspace this badly when we finally do get a version we want to upstream properly. GPU drivers are not just a kernel bit, they are not like a network card or sound driver, where the userspace API is mostly defined or a filesystem where we have POSIX. So really I'm NAKing this from ever entering the mainline in its current form, without a supporting roadmap and plans for the userspace bits. Dave. > > thanks, > > greg k-h > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
