Re: [RFC] full suspend/resume support for i915 DRM driver
On Thursday, October 18, 2007 2:01 pm Jesse Barnes wrote:
> We seem to see a lot of bug reports along the lines of, "my machine
> resumes but I can't see X" or, "I can see X but only with a bright
> flashlight", etc. These sorts of problems are due to the fact that
> the X server isn't designed to do full state save/restore, and none
> of the available kernel drivers do it on its behalf.
>
> Since intelfb and the rest of the Intel drivers are fairly
> incompatible, this patch makes the DRM bind to the PCI device so it
> can register real suspend/resume handlers. Those handlers take care
> of saving and restoring enough state for X to come back reliably on
> at least one of my problematic test machines, but text mode still has
> trouble (still debugging VGA state save/restore, including trying to
> save/restore actual VRAM contents for possible hibernate support).
>
> How does this approach look? Is a new DRM driver flag a good thing
> for similar situations with other drivers? Thoughts?
Here's an updated one that actually works fully on my 965 based test
platform. It should also work on other 9xx platforms, but note that it
lacks TV out and SDVO state save/restore, so I don't expect those to
work. I also haven't tested on 8xx platforms, but a similar approach
should work, so I'd welcome additions to support those chipsets.
Dave can you take a look at the new flag and also see what you think
about supporting suspend/resume in the event X hasn't started yet?
There's some #if 0'd code to support that case, but I haven't tested
it.
Thanks,
Jesse
diff --git a/linux-core/Kconfig b/linux-core/Kconfig
index 2d02c76..5e73fc7 100644
--- a/linux-core/Kconfig
+++ b/linux-core/Kconfig
@@ -50,7 +50,7 @@ config DRM_I810
choice
prompt "Intel 830M, 845G, 852GM, 855GM, 865G"
- depends on DRM && AGP && AGP_INTEL
+ depends on DRM && AGP && AGP_INTEL && !FB_INTEL
optional
config DRM_I915
@@ -60,6 +60,9 @@ config DRM_I915
852GM, 855GM, 865G, 915G, 915GM, 945G, 945GM and 965G integrated
graphics. If M is selected, the module will be called i915.
AGP support is required for this driver to work.
+
+ Note that this driver is incompatible with the Intel framebuffer
+ driver.
endchoice
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index f8ca3f4..36ce266 100644
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -106,6 +106,7 @@ struct drm_file;
#define DRIVER_DMA_QUEUE 0x200
#define DRIVER_FB_DMA 0x400
#define DRIVER_IRQ_VBL20x800
+#define DRIVER_BIND_PCI0x1000
/[EMAIL PROTECTED]/
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
index a09fa96..4d11707 100644
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -340,9 +340,10 @@ int drm_init(struct drm_driver *driver,
}
}
- if (!drm_fb_loaded)
+ if (!drm_fb_loaded || (driver->driver_features & DRIVER_BIND_PCI)) {
+ printk(KERN_ERR "DRM binding to PCI device\n");
return pci_register_driver(&driver->pci_driver);
- else {
+ } else {
for (i = 0; pciidlist[i].vendor != 0; i++) {
pid = &pciidlist[i];
diff --git a/linux-core/i915_drv.c b/linux-core/i915_drv.c
index e337e1d..809ef0d 100644
--- a/linux-core/i915_drv.c
+++ b/linux-core/i915_drv.c
@@ -69,6 +69,501 @@ static struct drm_bo_driver i915_bo_driver = {
};
#endif
+enum pipe {
+PIPE_A = 0,
+PIPE_B,
+};
+
+static bool i915_pipe_enabled(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (pipe == PIPE_A)
+ return (I915_READ(DPLL_A) & DPLL_VCO_ENABLE);
+ else
+ return (I915_READ(DPLL_B) & DPLL_VCO_ENABLE);
+}
+
+static void i915_save_palette(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long reg = pipe == PIPE_A ? PALETTE_A : PALETTE_B;
+ u32 *array;
+ int i;
+
+ if (!i915_pipe_enabled(dev, pipe))
+ return;
+
+ if (pipe == PIPE_A)
+ array = dev_priv->savePaletteA;
+ else
+ array = dev_priv->savePaletteB;
+
+ for(i = 0; i < 256; i++)
+ array[i] = I915_READ(reg + (i << 2));
+}
+
+static void i915_restore_palette(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ unsigned long reg = pipe == PIPE_A ? PALETTE_A : PALETTE_B;
+ u32 *array;
+ int i;
+
+ if (!i915_pipe_enabled(dev, pipe))
+ return;
+
+ if (pipe == PIPE_A)
+ array = dev_priv->savePaletteA;
+ else
+ array = dev_priv->savePaletteB;
+
+ for(i = 0; i < 256; i++)
+ I915_WRITE(reg + (i << 2), array[i]);
+}
+
+static u8 i915_read_indexed(u16 index_port, u16 data_port, u8 reg)
+{
+ outb(reg, index
Re: [patch] post superioctl inteface removal.
Hi. Eric Anholt wrote: >On Thu, 2007-10-18 at 07:55 +0800, Keith Packard wrote: > > >>On Wed, 2007-10-17 at 16:40 -0700, Eric Anholt wrote: >> >> >> >>>Turn off CRTCs >>>Unpin old framebuffer >>>Allocate new framebuffer >>>Copy from old to new >>> >>> >>We needn't copy on resize, leaving us with allocate new, unpin old, pin >>new, free old. Seems like this would avoid some of the worst issues. >> >> > >True. The issue would still exist if you happened to accelerated clear >your new frontbuffer before pinning it, which we could avoid in the >driver. And even if you do everything right, in the case of expanding >your framebuffer I don't think there would be any guarantee of getting >put at the least-fragmenting place to have a pinned buffer. > >I think the solution to that that I suggested is reasonable and deals >with thomas's and our fragmentation concerns (don't use validate, just >find the space we would most like to be at not containing pinned >objects, evict whoever's there, and pin it). > > > Hmm, I missed this message somehow. Anyway, this scheme seems to be the best solution to avoid pinned buffer fragmentation. However it's not straightforward to implement with the current code. One way would be to decide on a target memory region, do a full memory region clean on that one (keeping only pinned buffers) and then let the default logic handle the rest. >Also, while I'm not a fan of the vague name of drmBOSetStatus, it sounds >like it would be usable to do the map hinting I suggested. > > > It would. If we're going to change the name we'd better do it now. Any suggestions? /Thomas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] post superioctl inteface removal.
On Fri, 2007-10-19 at 03:04 +0200, Jerome Glisse wrote: > Kristian Høgsberg wrote: > > On 10/18/07, Keith Whitwell <[EMAIL PROTECTED]> wrote: > > ... > > > >>> Doesn't Kristian changes to DRI interface (DRI2) already allow to > >>> clients to not care > >>> about front buffer. I mean if they all got private back buffer then they > >>> render into it. > >>> But i might have misunderstood this. > >>> > >> Yes, of course. I'm not sure how watertight the isolation of the > >> frontbuffer is in DRI2, but if it's complete and if the rule is that ttm > >> supports only DRI2 clients, this concern would seem to be addressed. > >> > > > > What I'm planning to do is to keep the front buffer bo handle in the > > kernel, associateed with the drm_drawable_t. The swap buffer ioctl > > will reference a drm_drawable_t as the front buffer destination and > > thus it will always be up to date and userspace won't hold any > > references to front buffers. The kernel holds a reference through > > each of the drm_drawable_t's that are non-redirected child-windows of > > the front buffer, and once the X server has re-attached the new front > > buffer bo to each drm_drawable_t, there should be no references to the > > front buffer. This happens in the SetWindowPixmap hook. > > > > It sounds like we want to free the old front buffer before we allocate > > the new one, in which case we'll have to call the SetWindowPixmap hook > > with a null pixmap or something to drop the kernel side references > > before allocating the new buffer. > > > > However, I was hoping we could avoid this, and allocate a new buffer > > while still scanning out from the old one, copy the contents, change > > the scan out address and then free the old one. This avoids flicker, > > and as for the fragmentation concern; can't we just alternate between > > allocating from different ends of the aperture? Or alternatively, do > > a two-step operation: allocate a temporary front buffer far enough > > into the aperture that we free the old buffer and then allocate the > > final new frontbuffer at offset 0? We should avoid turning off the > > crtcs here if at all possible. > > > > cheers, > > Kristian > > > > There is also the following (i don't think it was mentioned before > in this thread): >card with 8Mo of ram (who the hell have such hw ? :)) a scanout >buffer which use 4Mo and user resizing to buffer which need 5Mo >obviously we can't allocate it until we free the previous one... Maybe >we can accept some kind of allocate over style or simply a resize >function. No, you can't validate or pin the new one until you unpin the old one. Creation is fine, and validation is fine as long as old is unpinned. It can be referenced still -- who cares? Are we really trying to optimize out the migration of the old buffer to system memory when it's about to be thrown away? -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8357] Rendering with r300 right of 2650px width is disstorted
http://bugs.freedesktop.org/show_bug.cgi?id=8357 --- Comment #9 from [EMAIL PROTECTED] 2007-10-05 10:53 PST --- It looks like you are right, becouse I could get opengl working up to ~2650 pixels. So anyone knows why we need this magic with R300_CLIPRECT_OFFSET in r300_cmdbuf.c in drm? --- Comment #10 from [EMAIL PROTECTED] 2007-10-19 06:31 PST --- Thanks for holp, but with my limited knowledge about inner workings of r300 drm module I failed to solve problem with R300_CLIPRECT_OFFSET and cliprect, scissoring working. So without any further help I'm not able to solve this problem. I hope someone else will step in with more knowledge and will solve this limitation in the future. Thanks -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
