[lkml]   [2009]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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 driver available for this yet, Ubuntu
    shipped something
    but really we should be at least seeing 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.


    > thanks,
    > greg k-h
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to
    > More majordomo info at
    > Please read the FAQ at
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-03-19 07:51    [W:0.024 / U:21.800 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site