LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Greg KH <greg@kroah.com>
Cc: Dave Airlie <airlied@gmail.com>,
	airlied@linux.ie, linux-kernel@vger.kernel.org
Subject: Re: gpu sharing layer for kernel
Date: Sun, 28 Jan 2007 16:16:46 -0500	[thread overview]
Message-ID: <20070128211646.GC23903@redhat.com> (raw)
In-Reply-To: <20070125220631.GB5886@kroah.com>

On Thu, Jan 25, 2007 at 02:06:31PM -0800, Greg Kroah-Hartman wrote:
 > On Thu, Jan 25, 2007 at 09:39:47AM +1100, Dave Airlie wrote:
 > > >> Why do we want this?
 > > >>
 > > >> Currently the kernel cannot provide both the fb and drm drivers with
 > > >> access to the device model and this means the drm cannot get any
 > > >> suspend/resume callbacks.  This layer attempts to fix this problem by
 > > >> adding a bus for the gpu drivers to attach to. Currently a lowlevel
 > > >> binding driver is needed along with optional fb and drm components.
 > > >
 > > >If we were to allow this kind of "sharing" for all PCI devices would
 > > >that work out instead?  Or would this layer still be needed?
 > > 
 > > Initially this layer wouldn't be needed, but I'd like to add some
 > > awareness to the drivers, so the drm can tell the fb to stop doing
 > > stuff and vice-versa if necessary....  but perhaps that could be done
 > > with a generic layer also.. or via the lowlevel driver I have...
 > 
 > Ok, I have no objection to this layer right now, as it solves your
 > problem, and while I would like some time in the future to add such a
 > layer for the PCI devices, it is no where on my todo plate just yet...

It's been bubbling its way up my todo too, as agpgart is starting to
get bug reports due to conflicts when the EDAC drivers or watchdog
drivers 'claim' the south bridge ID before agp gets a chance to init.

Someone sent me some patches a few weeks back, but I seem to have mislaid
them. I'll turf them up and get the sender to send them to lkml.
They should at the least, make a starting point.

		Dave

-- 
http://www.codemonkey.org.uk

  reply	other threads:[~2007-01-28 21:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-24 11:20 airlied
2007-01-24 11:20 ` [PATCH] gpu: Initial gpu layer addition airlied
2007-01-24 11:20   ` [PATCH] gpu/radeon: add a radeon lowlevel GPU driver airlied
2007-01-24 11:20     ` [PATCH] gpu/radeonfb: add GPU support to radeonfb airlied
2007-01-24 11:20       ` [PATCH] gpu/drm: Add GPU layer support to generic DRM airlied
2007-01-24 11:20         ` [PATCH] drm/gpu/radeon: Add radeon DRM support to use GPU layer airlied
2007-01-25  0:07       ` [PATCH] gpu/radeonfb: add GPU support to radeonfb Benjamin Herrenschmidt
2007-01-30 19:50         ` Dave Airlie
2007-01-24 21:46 ` gpu sharing layer for kernel Greg KH
2007-01-24 22:39   ` Dave Airlie
2007-01-25 22:06     ` Greg KH
2007-01-28 21:16       ` Dave Jones [this message]
2007-02-07 18:42     ` James Simmons
2007-02-06 19:40   ` James Simmons
2007-01-25  7:56 ` Paul Collins
2007-01-30 19:49   ` Dave Airlie

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=20070128211646.GC23903@redhat.com \
    --to=davej@redhat.com \
    --cc=airlied@gmail.com \
    --cc=airlied@linux.ie \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: gpu sharing layer for kernel' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).