[patch 1/5] drm: Split out the mm declarations in a separate header. Add atomic operations.
Dave Airlie
> 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 majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Thomas Hellström
Some quick comments below.
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 majo...@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-...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
Alan Cox
> 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
Richard Purdie
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
Sindhudweep Sarkar
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 <gr...@kroah.com> 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
Greg KH
> 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...
Richard Purdie
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
Sindhudweep Sarkar
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
Matthew Garrett
> 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
Greg KH
> 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
Matthew Garrett
> On Thu, Mar 19, 2009 at 06:53:38PM +0000, 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
Greg KH
> On Thu, Mar 19, 2009 at 12:02:54PM -0700, Greg KH wrote:
> > On Thu, Mar 19, 2009 at 06:53:38PM +0000, 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
Greg KH
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...)
Greg KH
>> 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 KH
> > 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
Greg KH
> 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.
Corbin Simpson
> 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.
Thomas Hellström
> 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
>
A clean TTM patch was sent to Intel with the other patches.
I'm not sure why it got lost along the way?
/Thomas
Sindhudweep Sarkar
>
> 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?
Greg KH
> 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?
>>
> 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
Daniel Stone
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
Greg KH
The license of the NVIDIA driver does not allow that to even be a
possibility.
Alan Cox
> > 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.
Greg KH
> > > 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
Thomas Hellström
> On Fri, Mar 20, 2009 at 03:00:32PM +0000, 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
>
>
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
Greg KH
> 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