public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@linux.intel.com>
To: Dave Airlie <airlied@gmail.com>
Cc: Greg KH <greg@kroah.com>, David Airlie <airlied@linux.ie>,
	dri-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	Thomas Hellstrom <thellstrom@vmware.com>
Subject: Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core  changes
Date: Thu, 19 Mar 2009 10:43:57 +0000	[thread overview]
Message-ID: <1237459437.5359.50.camel@dax.rpnet.com> (raw)
In-Reply-To: <21d7e9970903182348v57a78188ocefe138d353ee197@mail.gmail.com>

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




  parent reply	other threads:[~2009-03-19 10:43 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20090319035834.875839585@mini.kroah.org>
2009-03-19  4:08 ` [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes Greg KH
2009-03-19  4:08   ` [patch 1/5] drm: Split out the mm declarations in a separate header. Add atomic operations Greg KH
2009-03-19  4:08   ` [patch 4/5] drm: Add unlocked IOCTL functionality from the drm repo Greg KH
2009-03-19  4:08   ` [patch 3/5] drm: Export hash table functionality Greg KH
2009-03-19  4:08   ` [patch 2/5] drm: Add a tracker for global objects Greg KH
2009-03-19  6:48   ` [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes Dave Airlie
2009-03-19 10:14     ` Thomas Hellström
2009-03-19 10:39       ` Alan Cox
2009-03-19 20:13         ` Greg KH
2009-03-19 20:11       ` Greg KH
2009-03-19 20:40         ` Thomas Hellström
2009-03-20  0:23           ` Greg KH
2009-03-20 14:17             ` Thomas Hellström
2009-03-19 10:43     ` Richard Purdie [this message]
2009-03-19 20:10     ` Greg KH
2009-03-19 16:03   ` Sindhudweep Sarkar
2009-03-19 16:27     ` Greg KH
2009-03-19 18:11       ` Sindhudweep Sarkar
2009-03-19 20:14         ` Greg KH
2009-03-19 18:53       ` Matthew Garrett
2009-03-19 19:02         ` Greg KH
2009-03-19 19:05           ` Matthew Garrett
2009-03-19 19:20             ` Greg KH
2009-03-20  6:08       ` Daniel Stone
2009-03-20 14:53         ` Greg KH
2009-03-20 15:00           ` Alan Cox
2009-03-20 15:50             ` Greg KH
2009-03-20 16:59               ` Thomas Hellström
2009-03-19 17:12     ` Richard Purdie
2009-03-19 20:15       ` Corbin Simpson
2009-03-19 21:14         ` Sindhudweep Sarkar
2009-03-21  2:39   ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1237459437.5359.50.camel@dax.rpnet.com \
    --to=rpurdie@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thellstrom@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox