Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM corechanges

From: Thomas Hellström
Date: Fri Mar 20 2009 - 10:18:42 EST


This is a multi-part message in MIME format.Greg KH wrote:
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
So, a beer it is :)

I'm attaching it with the latest TTM bugfixes and passing checkpatch.pl.
Note that this is against the DRM tree, not the staging tree.

Actually, there are two patches. One exporting the X86 PAT pgprot_writecombine functionality, as the
psb / mrst architecture is dependant on it. There's no IO region we can write-combine like for a traditional GPU, and not even the VDC GTT supports traditional write-combining.

The psb / mrst part is not included, though but it should be sufficient just to replace the ttm files
and remove those files not in this patch.

Now while we're at it, we could perhaps discuss the placement of TTM.
It will probably see some continous evolvement; Dave has suggested it being a submodule on its own,
but nothing that should stop upstream merging or have a dramatic impact on the in-kernel interfaces.
And there is another user of TTM as well, the openChrome drm module.
It's user mode interface is quite fixed save for the video decoder functionality, and that can be stripped until there is user-space support, so this module is probably mature enough to go at least into the staging tree if not mainstream.

That would suggest placing TTM not as a subdirectory of the psb module but as a freestanding subdirectory either of drm in mainstream or in staging. Suggestions?

I attach the patches to the mail, rather than sending them standalone as they will likely need some massaging by Greg.

/Thomas