On Saturday 09 January 2010, Dave Airlie wrote: > On Sat, Jan 9, 2010 at 11:35 PM, Rafael J. Wysocki <r...@sisk.pl> wrote: > > On Saturday 09 January 2010, Jesse Barnes wrote: > >> On Fri, 8 Jan 2010 16:50:57 -0800 (PST) > >> Linus Torvalds <torva...@linux-foundation.org> wrote: > >> > >> > > >> > > >> > On Sat, 9 Jan 2010, Rafael J. Wysocki wrote: > >> > > > >> > > Which is functionally equivalent to my patch, because > >> > > i915_suspend/resume() won't be called by drm_class_suspend/resume() > >> > > in the KMS case anyway. > >> > > >> > Ahh, right you are - that class suspend function does a check for > >> > DRIVER_MODESET, and only does the suspend/resume if it's not a > >> > MODESET driver. > >> > > >> > Ok, so I withdraw my objections to your original patch - it's > >> > confusing, but that's just because DRM is such a horrible mess with > >> > subtle things. > >> > >> Yeah the non-KMS paths just suck. > >> > >> Acked-by: Jesse Barnes <jbar...@virtuousgeek.org> > >> > >> Though hopefully you can get the PCI driver registration working w/o > >> too much trouble; that would be even better. > > > > Actually, I have a working patch, with one tiny detail I'm not sure of. > > > > Namely, I need to call pci_set_drvdata(pdev, dev) unconditionally in > > drm_stub.c > > for the things to work, but I _think_ it won't hurt even if we're not going > > to > > use the pdev's private data. > > > > The benefit of this is having just one code path for suspend/resume instead > > of > > two different code paths depending on whether the driver is using the KMS or > > not, which is well worth it IMO. > > > > The patch is appended. > > NAK > > for the reasons I explained in the previous email. This conflicts with systems > where intelfb and intel drm are used together, this is something that ppl do > use > prior to KMS happening. > > We just need to document in the headers why the hooks are needed, > and maybe a bit of patch review to make sure nobody removes them again.
OK, so my original patch is the right one in that case. Rafael ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
