public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Greg KH <gregkh@suse.de>
Cc: dri-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@sisk.pl>, Pavel Machek <pavel@ucw.cz>
Subject: Re: [RFC] full suspend/resume support for i915 DRM driver
Date: Fri, 26 Oct 2007 09:57:14 -0700	[thread overview]
Message-ID: <200710260957.15137.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <20071026045950.GA22920@suse.de>

On Thursday, October 25, 2007 9:59 pm Greg KH wrote:
> On Thu, Oct 25, 2007 at 04:53:18PM -0700, Jesse Barnes wrote:
> > Ok, here's yet another version that uses the device model for the
> > suspend/resume, rather than pci hooks.
> >
> > Greg, DRM desperately needs review of its device model usage, can
> > you take a look at this patch and the current drm_sysfs.c code? 
> > Right now, we're mixing class_devices and regular devices (the
> > latter seem to be required for suspend/resume to work correctly),
> > but this seems wrong. Any ideas?  Should we just rip out the
> > class_device stuff and create full-on DRM device nodes?
>
> The class_device stuff is already ripped out in the latest -mm trees
> and I will be forwarding that change on for 2.6.25 after 2.6.24 is
> out.  So yes, it should be taken away :)
>
> But converting from class_device to struct device does not mean you
> use a "device node".  But you could if you want to :)

Yeah, bad choice of words. :)

To retain compatibility, we need to have directories under the DRM class 
dir (/sys/class/drm) for each card (e.g. card0) that contains a file 
describing which graphics driver is bound to the device.  For class 
devices, we could just add an attributes structure to the device.  Can 
we do the same with regular, non-class devices?

Thanks,
Jesse

  reply	other threads:[~2007-10-26 16:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-18 21:01 [RFC] full suspend/resume support for i915 DRM driver Jesse Barnes
2007-10-20  2:51 ` Jesse Barnes
2007-10-23  4:15   ` Jesse Barnes
2007-10-24 20:17     ` Adrian Bunk
2007-10-24 21:07       ` Jesse Barnes
2007-10-24 13:35 ` Pavel Machek
2007-10-24 15:18   ` Jesse Barnes
2007-10-24 21:22     ` Rafael J. Wysocki
2007-10-25 23:53       ` Jesse Barnes
2007-10-26  4:59         ` Greg KH
2007-10-26 16:57           ` Jesse Barnes [this message]
2007-10-26 17:10             ` Kay Sievers
2007-10-26 18:12               ` Jesse Barnes
2007-10-26 18:21                 ` Kay Sievers
2007-10-26 18:40               ` fixing up DRM device model usage Jesse Barnes
2007-10-26 19:08                 ` Kay Sievers
2007-10-26 21:31                   ` Jesse Barnes
2007-10-27 21:12                     ` Kay Sievers

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=200710260957.15137.jbarnes@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /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