Re: [RFC] drm: emit change events when mode config changes
On Fri, 15 Apr 2011 09:23:38 -0500
Chris Bandy cba...@jbandy.com wrote:
On 04/14/2011 12:42 PM, Jesse Barnes wrote:
/**
+ * drm_sysfs_change_event - generate a DRM uevent indicating a display
config change
+ * @dev: DRM device
+ *
+ * Send a uevent for the DRM device specified by @dev. Set CHANGE=1 to
+ * indicate that a userspace initiated display configuration change
occurred.
+ */
+void drm_sysfs_change_event(struct drm_device *dev)
+{
+ char *event_string = CHANGE=1;
+ char *envp[] = { event_string, NULL };
+
+ DRM_DEBUG(generating hotplug event\n);
Should be change event here?
Yeah, I noticed after I sent it out, I think I'll just drop the
DRM_DEBUG altogether though.
--
Jesse Barnes, Intel Open Source Technology Center
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] drm: emit change events when mode config changes
We've already seen that apps want to monitor the display config, and
some (like upowerd) poll for changes since we don't provide a
notification for general mode config changes, just hotplug events. So
add a new drm event, with CHANGE=1 set in the event, to allow for it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4c95b5f..174ee64 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1589,6 +1589,8 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
set.fb = fb;
ret = crtc-funcs-set_config(set);
+ drm_sysfs_change_event(dev);
+
out:
kfree(connector_set);
mutex_unlock(dev-mode_config.mutex);
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9507204..df946d4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -822,6 +822,8 @@ int drm_fb_helper_set_par(struct fb_info *info)
return ret;
}
}
+
+ drm_sysfs_change_event(dev);
mutex_unlock(dev-mode_config.mutex);
if (fb_helper-delayed_hotplug) {
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 2eee8e0..fd3af31 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -467,9 +467,9 @@ EXPORT_SYMBOL(drm_sysfs_connector_remove);
* drm_sysfs_hotplug_event - generate a DRM uevent
* @dev: DRM device
*
- * Send a uevent for the DRM device specified by @dev. Currently we only
- * set HOTPLUG=1 in the uevent environment, but this could be expanded to
- * deal with other types of events.
+ * Send a uevent for the DRM device specified by @dev. Set HOTPLUG=1 in the
+ * event to indicate a display config change occurred, probably due to a
+ * display being added or removed.
*/
void drm_sysfs_hotplug_event(struct drm_device *dev)
{
@@ -483,6 +483,24 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
/**
+ * drm_sysfs_change_event - generate a DRM uevent indicating a display config
change
+ * @dev: DRM device
+ *
+ * Send a uevent for the DRM device specified by @dev. Set CHANGE=1 to
+ * indicate that a userspace initiated display configuration change occurred.
+ */
+void drm_sysfs_change_event(struct drm_device *dev)
+{
+ char *event_string = CHANGE=1;
+ char *envp[] = { event_string, NULL };
+
+ DRM_DEBUG(generating hotplug event\n);
+
+ kobject_uevent_env(dev-primary-kdev.kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_change_event);
+
+/**
* drm_sysfs_device_add - adds a class device to sysfs for a character driver
* @dev: DRM device to be added
* @head: DRM head in question
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index ad5770f..3aff8fc 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1506,6 +1506,7 @@ extern struct class *drm_sysfs_create(struct module
*owner, char *name);
extern void drm_sysfs_destroy(void);
extern int drm_sysfs_device_add(struct drm_minor *minor);
extern void drm_sysfs_hotplug_event(struct drm_device *dev);
+extern void drm_sysfs_change_event(struct drm_device *dev);
extern void drm_sysfs_device_remove(struct drm_minor *minor);
extern char *drm_get_connector_status_name(enum drm_connector_status status);
extern int drm_sysfs_connector_add(struct drm_connector *connector);
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lenovo resume from suspends hangs in i915_gpu_busy or so
On Fri, 1 Apr 2011 14:15:11 +0900 Norbert Preining prein...@logic.at wrote: Hi all, adding dri-devel as I found it is actually not completely dead, but hanging in some i915 problem. Copyied from screen: Process ips-adjust ( Stack: ... Call Trace: IRQ ... ? tick_program_event call_sortirq do_softirq irq_exit smp_apic_timer_interrupt apic_timer_interrupt EOI ? _raw_spin_lock i915_gpu_busy ips_adjust ? show_cpu_temp kthread kernel_thread_helper ? kthread_worker_fn ? gs_change Code: ... (once more more or less the same as above) Hm, ok so on resume we're checking GPU busyness, which is normal, but end up hanging on the spinlock? Do you see what scrolls by above the text you took a picture of (probably a task hung message?). Does this happen reliably? Does a previous kernel work ok? -- Jesse Barnes, Intel Open Source Technology Center -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Fix support for PCI domains
On Fri, 13 Aug 2010 09:33:35 +1000
Dave Airlie airl...@gmail.com wrote:
On Fri, Aug 13, 2010 at 7:30 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Fri, Aug 6, 2010 at 05:55, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
(For some reason I thought that went in ages ago ...)
This fixes support for PCI domains in what should hopefully be a backward
compatible way along with a change to libdrm.
When the interface version is set to 1.4, we assume userspace understands
domains and the world is at peace. We thus pass proper domain numbers
instead of 0 to userspace.
The newer libdrm will then try 1.4 first, and fallback to 1.1, along with
ignoring domains in the later case (well, except on alpha of course)
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/drm_ioctl.c | 1 +
include/drm/drmP.h | 18 +-
include/drm/drm_core.h | 2 +-
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c1b9871..6d4bad5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1071,11 +1071,19 @@ static __inline__ int
drm_core_check_feature(struct drm_device *dev,
return ((dev-driver-driver_features feature) ? 1 : 0);
}
-#ifdef __alpha__
-#define drm_get_pci_domain(dev) dev-hose-index
-#else
-#define drm_get_pci_domain(dev) 0
-#endif
+static inline int drm_get_pci_domain(struct drm_device *dev)
+{
+#ifndef __alpha__
+ /* For historical reasons, drm_get_pci_domain() is busticated
+ * on most archs and has to remain so for userspace interface
+ * 1.4, except on alpha which was right from the beginning
+ */
+ if (dev-if_version 0x10004)
+ return 0;
+#endif /* __alpha__ */
+
+ return pci_domain_nr(dev-pdev-bus);
error: implicit declaration of function ‘pci_domain_nr’
on m68k without PCI.
I don't think I want to add an ifdef CONFIG_PCI into the drm layer for
this, since we seem to be okay everywhere else,
lets ask jbarnes, not sure if its safe to just add this to the
!CONFIG_PCI section of the linux/pci.h
Hm, so pci_domain_nr should just return 0 on platforms where
CONFIG_PCI_DOMAINS isn't set. I'd expect that to be the case when
CONFIG_PCI=n... Maybe we just need to shuffle the definition around?
--
Jesse Barnes, Intel Open Source Technology Center
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Fix support for PCI domains
Hm, so pci_domain_nr should just return 0 on platforms where CONFIG_PCI_DOMAINS isn't set. I'd expect that to be the case when CONFIG_PCI=n... Maybe we just need to shuffle the definition around? I suspect something like the attached would suffice. Or maybe moving the CONFIG_PCI_DOMAINS checkout outside CONFIG_PCI. Yeah, that looks ok, and better than putting it in drm. I'll apply to my for-linus branch for the next PCI fixes pull. Thanks, Jesse -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.35-rc4-git3: Reported regressions from 2.6.34
On Thu, 8 Jul 2010 18:34:25 -0700 Linus Torvalds torva...@linux-foundation.org wrote: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16307 Subject : i915 in kernel 2.6.35-rc3, high number of wakeups Submitter : Enrico Bandiello en...@postal.uv.es Date : 2010-06-26 16:57 (13 days old) Message-ID : 4c26317a.5070...@postal.uv.es References : http://marc.info/?l=linux-kernelm=127757403404259w=2 I don't think anybody noticed this one. Jesse? Oh I hadn't seen that... Enrico, can you bisect this issue? It could be some spurious hotplug events or possibly a stuck vblank interrupt... Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16265 Subject : Why is kslowd accumulating so much CPU time? Submitter : Theodore Ts'o ty...@mit.edu Date : 2010-06-09 18:36 (30 days old) First-Bad-Commit: http://git.kernel.org/linus/fbf81762e385d3d45acad057b654d56972acf58c Message-ID : e1omq88-0002a1...@closure.thunk.org References : http://marc.info/?l=linux-kernelm=127610857819033w=4 Dave, Jesse? I haven't looked at the switchable graphics stuff, hopefully Dave has an idea here. Fixed by commit f4985dc714d7. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228 Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine) Submitter : Brian Bloniarz phun...@hotmail.com Date : 2010-06-16 17:57 (23 days old) Handled-By : Bjorn Helgaas bjorn.helg...@hp.com This has a butt-ugly suggested patch that certainly won't be applied. I saw the thread, but lost sight of it. Jesse, did that end up with some resolution? I'll follow up with Yinghai, we were pretty clear about what we wanted from that patch. Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16179 Subject : 2.6.35-rc2 completely hosed on intel gfx? Submitter : Norbert Preining prein...@logic.at Date : 2010-06-06 11:55 (33 days old) Message-ID : 20100606115534.ga9...@gamma.logic.tuwien.ac.at References : http://marc.info/?l=linux-kernelm=127582534931581w=2 Hmm. That one is the vt.c bug coupled with another problem, which in turn got opened as a separate bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=16252 which in turn then got closed. I dunno. Yeah, this is weird. Norbert, do you still see this? Have you tried to bisect it? -- Jesse Barnes, Intel Open Source Technology Center -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Implement direct pineview backlight control.
On Tue, 22 Jun 2010 16:58:27 -0700 Bryan Freed bfr...@chromium.org wrote: drm/i915: Add a direct interface for pineview backlight support. This adds a Kconfig variable CONFIG_DRM_I915_DIRECT_BACKLIGHT to optionally include the new source file i915_backlight.c. This file registers a couple backlight set/get routines with the standard drivers/video/backlight interface to add a directory under /sys/class/backlight/. The big problem I see with this modification is that the i915 driver _already_ supports backlight level adjustment in i915_opregion.c. Unfortunately, that requires an IRQ to occur as the result of writing some ASLE (ACPI Source Language Event) register, and this requires BIOS support for the ACPI hook. It looks like we will not have such support in our initial custom BIOS. So I copy a small amount of code from i915_opregion.c to make backlight adjustment directly available to the backlight framework. Another problem is that I do not cover all the cases handled by the i915_opregion.c code. It would be too much untested code copying to do so. I enforce the lack of support by checking for IS_PINEVIEW() in i915_backlight_init(). Review URL: http://codereview.chromium.org/2830015 Signed-off-by: Bryan Freed bfr...@chromium.org How does this compare to Matthew's native backlight support? AFAIK that patch is still outstanding due to the need for some changes to the backlight subsystem. Matthew? -- Jesse Barnes, Intel Open Source Technology Center -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vt/console: try harder to print output when panicing
On Wed, 23 Jun 2010 13:12:59 +1000 Dave Airlie airl...@gmail.com wrote: From: Jesse Barnes jbar...@virtuousgeek.org Jesse's initial patch commit said: At panic time (i.e. when oops_in_progress is set) we should try a bit harder to update the screen and make sure output gets to the VT, since some drivers are capable of flipping back to it. So make sure we try to unblank and update the display if called from a panic context. I've enhanced this to add a flag to the vc that console layer can set to indicate they want this behaviour to occur. This also adds support to fbcon for that flag and adds an fb flag for drivers to indicate they want to use the support. It enables this for KMS drivers. Signed-off-by: Dave Airlie airl...@redhat.com --- Yeah this looks a little nicer, thanks. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vt/console: try harder to print output when panicing
On Wed, 23 Jun 2010 12:56:05 -0700 Andrew Morton a...@linux-foundation.org wrote: On Wed, 23 Jun 2010 13:12:59 +1000 Dave Airlie airl...@gmail.com wrote: Jesse's initial patch commit said: At panic time (i.e. when oops_in_progress is set) we should try a bit harder to update the screen and make sure output gets to the VT, since some drivers are capable of flipping back to it. So make sure we try to unblank and update the display if called from a panic context. I've enhanced this to add a flag to the vc that console layer can set to indicate they want this behaviour to occur. This also adds support to fbcon for that flag and adds an fb flag for drivers to indicate they want to use the support. It enables this for KMS drivers. Interesting. Getting real oops traces from machines running X will make Rusty happy, and that's what we're all here for. How well does this all work? How reliable is it? What's the success rate? What's the downside here? After all, not all oopses are catastrophic - sometimes the machine will go blurt and keep running so the user can take a look in the logs then perform an orderly reboot, etc. As I understand it, those non-catastrophic oopses will now flip the machine from X and into the vt display, yes? Can the user get it back to X mode? No, we'll only flip from the panic notifier chain. However if oops_in_progress is set (as it is whenever bust_spinlocks(1) is called, i.e. from panic() and oops_begin()) we'll try to print into the fbcon buffer. In the oops case this should still be safe since the buffer is pinned, at least in the KMS world. Worse, there's also a risk that doing all this new work within the oopsing context will screw the machine up, so the user will be _deprived_ of an oops report which he otherwise would have been able to get from the logs. This is particularly the case when it's the DRI stuff which oopsed, which is not exactly an uncommon occurrence lately ;) Oh well, the best way to tell is to ship-it-and-see. To avoid the oops part (which as I said should still be safe) we could add a new panic_in_progress flag, that would make sure things were no worse than they are currently. -- Jesse Barnes, Intel Open Source Technology Center -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vt/console: try harder to print output when panicing
On Wed, 23 Jun 2010 13:36:37 -0700 Andrew Morton a...@linux-foundation.org wrote: On Wed, 23 Jun 2010 13:05:47 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 23 Jun 2010 12:56:05 -0700 Andrew Morton a...@linux-foundation.org wrote: On Wed, 23 Jun 2010 13:12:59 +1000 Dave Airlie airl...@gmail.com wrote: Jesse's initial patch commit said: At panic time (i.e. when oops_in_progress is set) we should try a bit harder to update the screen and make sure output gets to the VT, since some drivers are capable of flipping back to it. So make sure we try to unblank and update the display if called from a panic context. I've enhanced this to add a flag to the vc that console layer can set to indicate they want this behaviour to occur. This also adds support to fbcon for that flag and adds an fb flag for drivers to indicate they want to use the support. It enables this for KMS drivers. Interesting. Getting real oops traces from machines running X will make Rusty happy, and that's what we're all here for. How well does this all work? How reliable is it? What's the success rate? What's the downside here? After all, not all oopses are catastrophic - sometimes the machine will go blurt and keep running so the user can take a look in the logs then perform an orderly reboot, etc. As I understand it, those non-catastrophic oopses will now flip the machine from X and into the vt display, yes? Can the user get it back to X mode? No, we'll only flip from the panic notifier chain. So we still don't get to see the output from BUGs and random oopses? I don't think panics are all that common. No, BUG() ends up in panic iirc by doing an bad pointer ref which should fault and panic. Random oopses won't show up though (but they're not supposed to be fatal and can be seen in the log). So am I correct in believing that if a user is getting invisible-oopses then he can set /proc/sys/kernel/panic_on_oops, and then the oops should be visible? Yep. (Shouldn't all this stuff be explained in the changlog?) Maybe? Linux oops/panic handling is pretty ad-hoc, a separate document would probably be best. -- Jesse Barnes, Intel Open Source Technology Center -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: output polling + disconnected operation
On Wed, 5 May 2010 11:12:13 +1000 Dave Airlie airl...@gmail.com wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a connector and claim it is connected when nothing else is, however this falls over, for DVI esp on a dual-DVI card. You pick a DVI connector, claim it is connected, you most likely end up turning on the analog portion of it, you hotplug a digital connector and the uevent gets sent, the client app repolls the connector status, sees the connector is still connected so doesn't do anything. Forcing a disconnect/connect is incredibly racy and hard. So Ben Skeggs suggested we just fake a disconnected connector for this case. It looks a bit messy in xrandr, but from what I can see the gnome client ignores it as it should. It's an ugly problem... When the hotplug event is received, wouldn't you re-probe and find a digital monitor attached? If so, that would mean a mode set sent in by the X server should end up being a full one since the current config is incompatible. Which means X just has to know it forced a mode, so when any event comes in it should re-set the mode unconditionally... Jesse -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 5/7] drm/i915: use vblank and vsync interrupts on 945
On Fri, 26 Mar 2010 11:07:19 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On 945, vblank delivery alone seems unreliable. The PIPE*STAT bits get set correctly, but interrupts occur at a low frequency relative to refresh. If we enable VSYNC interrupts as well however (even though we only check for VBLANK interrupts when handling) we get the right frequency. Increases OA performance on my AspireOne by about 300% with the new DRI2 bits, which rely on high frequency vblank events. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- Ignore this patch; it's still broken. Working on a fix now. -- Jesse Barnes, Intel Open Source Technology Center -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
List moved to freedesktop.org
Thanks to Tollef, we've just finished moving this list over to freedesktop.org. This should give us faster delivery and a better archive viewer. The new list address is dri-de...@lists.freedesktop.org. Old subscribers have automatically been subscribed to the new list, preserving existing subscription options related to delivery and digests. Have fun using the new list! -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: add locked variant of drm_fb_helper_force_kernel_mode
Needed for panic and kdb, since we need to avoid taking the mode_config
mutex. This patch gets us back to where we used to be, i.e. when a
panic occurs we'll switch to the fbcon buffer. I'm still working on
the VT layer to add better support for printing any outstanding
messages and/or switching to the VT with all the good stuff on it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_fb_helper.c | 42 +-
1 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6929f5b..962eadb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -242,18 +242,22 @@ static int drm_fb_helper_parse_command_line(struct
drm_fb_helper *fb_helper)
return 0;
}
-bool drm_fb_helper_force_kernel_mode(void)
+bool drm_fb_helper_force_kernel_mode_locked(void)
{
int i = 0;
bool ret, error = false;
struct drm_fb_helper *helper;
-
- if (list_empty(kernel_fb_helper_list))
- return false;
+ struct drm_mode_set *mode_set;
+ struct drm_crtc *crtc;
list_for_each_entry(helper, kernel_fb_helper_list, kernel_fb_list) {
for (i = 0; i helper-crtc_count; i++) {
- struct drm_mode_set *mode_set =
helper-crtc_info[i].mode_set;
+ mode_set = helper-crtc_info[i].mode_set;
+ crtc = helper-crtc_info[i].mode_set.crtc;
+
+ if (!crtc-enabled)
+ continue;
+
ret = drm_crtc_helper_set_config(mode_set);
if (ret)
error = true;
@@ -262,11 +266,37 @@ bool drm_fb_helper_force_kernel_mode(void)
return error;
}
+bool drm_fb_helper_force_kernel_mode(void)
+{
+ bool ret;
+ struct drm_device *dev;
+ struct drm_fb_helper *helper;
+ struct drm_mode_set *mode_set;
+
+ if (list_empty(kernel_fb_helper_list)) {
+ DRM_DEBUG_KMS(no fb helper list??\n);
+ return false;
+ }
+
+ /* Get the DRM device */
+ helper = list_first_entry(kernel_fb_helper_list,
+ struct drm_fb_helper,
+ kernel_fb_list);
+ mode_set = helper-crtc_info[0].mode_set;
+ dev = mode_set-crtc-dev;
+
+ mutex_lock(dev-mode_config.mutex);
+ ret = drm_fb_helper_force_kernel_mode_locked();
+ mutex_unlock(dev-mode_config.mutex);
+
+ return ret;
+}
+
int drm_fb_helper_panic(struct notifier_block *n, unsigned long ununsed,
void *panic_str)
{
DRM_ERROR(panic occurred, switching back to text console\n);
- return drm_fb_helper_force_kernel_mode();
+ drm_fb_helper_force_kernel_mode_locked();
return 0;
}
EXPORT_SYMBOL(drm_fb_helper_panic);
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Move lists to freedesktop.org?
On Thu, 8 Apr 2010 18:38:03 -0400 Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul bri...@vmware.com wrote: Unless there's some objection I'm going to subscribe everyone to the new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list. Probably in the next 24 hours. Then, some of you may have to log into the mailman interface (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest mode, etc. -Brian Are there plans to move dri-devel as well? Yeah, I'm just getting the info for that now. But I don't think we have subscriber lists, so everyone will have to re-subscribe to the new list. I'll send out a note to dri-devel when it's all set. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/7] drm/i915: fix page flipping on gen3
On Fri, 26 Mar 2010 13:41:08 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 26 Mar 2010 11:07:20 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
- if (iir I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT)
+ if ((iir I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT)
+ !(pipeb_stats pipe_vblank_mask)) {
+ DRM_ERROR(flip complete w/o vblank irq?\n);
+ }
Oops, this hunk definitely doesn't belong here. I'll post an update to
this one.
Updated patch w/o the extra debug statement.
---
From 34265649a24f92a9fa004d27ca869cc3dd750fe3 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri, 26 Mar 2010 10:35:20 -0700
Subject: [PATCH 1/3] drm/i915: fix page flipping on gen3
Gen3 chips have slightly different flip commands, and also contain a bit
that indicates whether a flip pending interrupt means the flip has
been queued or has been completed.
So implement support for the gen3 flip command, and make sure we use the
flip pending interrupt correctly depending on the value of ECOSKPD bit
0.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |4
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c | 16
drivers/gpu/drm/i915/i915_reg.h |4
drivers/gpu/drm/i915/intel_display.c | 29 -
drivers/gpu/drm/i915/intel_drv.h |1 +
6 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a9f8589..193bf16 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1475,6 +1475,10 @@ static int i915_load_modeset_init(struct drm_device *dev,
if (ret)
goto destroy_ringbuffer;
+ /* IIR flip pending bit means done if this bit is set */
+ if (IS_GEN3(dev) (I915_READ(ECOSKPD) ECO_FLIP_DONE))
+ dev_priv-flip_pending_is_done = true;
+
intel_modeset_init(dev);
ret = drm_irq_install(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index abf2713..4e41f0f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -608,6 +608,7 @@ typedef struct drm_i915_private {
struct drm_crtc *plane_to_crtc_mapping[2];
struct drm_crtc *pipe_to_crtc_mapping[2];
wait_queue_head_t pending_flip_queue;
+ bool flip_pending_is_done;
/* Reclocking support */
bool render_reclock_avail;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b16bb0d..79cbead 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -924,22 +924,30 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
mod_timer(dev_priv-hangcheck_timer, jiffies +
DRM_I915_HANGCHECK_PERIOD);
}
- if (iir I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT)
+ if (iir I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT) {
intel_prepare_page_flip(dev, 0);
+ if (dev_priv-flip_pending_is_done)
+ intel_finish_page_flip_plane(dev, 0);
+ }
- if (iir I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT)
+ if (iir I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT) {
intel_prepare_page_flip(dev, 1);
+ if (dev_priv-flip_pending_is_done)
+ intel_finish_page_flip_plane(dev, 1);
+ }
if (pipea_stats pipe_vblank_mask) {
vblank++;
drm_handle_vblank(dev, 0);
- intel_finish_page_flip(dev, 0);
+ if (!dev_priv-flip_pending_is_done)
+ intel_finish_page_flip(dev, 0);
}
if (pipeb_stats pipe_vblank_mask) {
vblank++;
drm_handle_vblank(dev, 1);
- intel_finish_page_flip(dev, 1);
+ if (!dev_priv-flip_pending_is_done)
+ intel_finish_page_flip(dev, 1);
}
if ((pipeb_stats PIPE_LEGACY_BLC_EVENT_STATUS) ||
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index df20187..9179b38 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -178,6 +178,7 @@
#define MI_OVERLAY_OFF (0x221)
#define MI_LOAD_SCAN_LINES_INCL MI_INSTR(0x12, 0)
#define MI_DISPLAY_FLIPMI_INSTR(0x14, 2)
+#define MI_DISPLAY_FLIP_I915 MI_INSTR(0x14, 1)
#define MI_DISPLAY_FLIP_PLANE(n) ((n) 20)
#define MI_STORE_DWORD_IMM MI_INSTR(0x20, 1)
#define MI_MEM_VIRTUAL (1 22) /* 965+ only
Re: intel graphic card hanging (Hangcheck timer elapsed... GPU hung)
On Tue, 30 Mar 2010 22:57:06 +0900 Norbert Preining prein...@logic.at wrote: On Mo, 29 Mär 2010, Jesse Barnes wrote: I was seeing something similar on my 945, can you try this patchset? Tried it with git kernel commit b72c409 and your patches, but didn't change anything. Starting d2x-xl killed the X server: [ 1067.920246] render error detected, EIR: 0x [ 1067.920293] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 48294 at 48216) [ 1068.412095] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [ 1068.412107] render error detected, EIR: 0x [ 1068.412135] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 48299 at 48216) [ 1068.776229] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Anything else I could try? One of my 945 machines became pretty stable after increasing the hancheck timeout from 75 to 750 jiffies in i915_drv.h. But I have reports that it doesn't work on all machines, so it's probably just covering up a bug somewhere else. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.20
New version includes a few fixes relative to 2.4.19.
Ben Skeggs (4):
nouveau: remove unused field from nouveau_bo
nouveau: fix segfault in nouveau_bo_new_tile() failure path
nouveau: fix annoying compiler warning
Fix pkgconfig includes for /usr/include/drm
Chris Wilson (2):
intel: Propagate some more error returns
intel: Repeat execbuffer if interrupted by signal
Eric Anholt (3):
intel: Only align Y-tiling pitch to the Y tile width.
intel: Align untiled buffer pitch to 64B.
intel: Install the header file in the libdrm/ directory.
Francisco Jerez (4):
nouveau: Update nouveau_class.h.
nouveau: Small lighting related addition to nouveau_class.h.
nouveau: Fix up the stride of NV20TCL_LIGHT_BACK_*.
nouveau: Regenerate nouveau_class.h.
Jerome Glisse (1):
drm/radeon: tab/whitespace cleanup
Jesse Barnes (2):
modetest: add optional select codepath
libdrm: bump version number to 2.4.20 for release
Julien Cristau (3):
libdrm_intel.pc: don't include ${includedir}/drm
libdrm_nouveau requires libdrm
Install headers to $(includedir)/libdrm
Pauli Nieminen (4):
libdrm: Move intel_atomic.h to libdrm core for sharing.
libdrm_radeon: Optimize cs_gem_reloc to do less looping.
libdrm: Fix error message if libdrm_intel|radeon is disabled and there is
no atomic ops.
Check HAVE_RADEON only after checking for atomic operations.
git tag: 2.4.20
http://dri.freedesktop.org/libdrm/libdrm-2.4.20.tar.bz2
MD5: 3c56e03172b236e14905ef9a68ba2f97 libdrm-2.4.20.tar.bz2
SHA1: f1448ac0f1c7a5f74a86d2fb50941fc12dc932db libdrm-2.4.20.tar.bz2
http://dri.freedesktop.org/libdrm/libdrm-2.4.20.tar.gz
MD5: dcbf9aa0497c84c7e4af15adb0021955 libdrm-2.4.20.tar.gz
SHA1: e492e292df048566f910244bf5e0a9a8f07039b6 libdrm-2.4.20.tar.gz
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Regression, post-rc2] Commit a5ee4eb7541 breaks OpenGL on RS780 (was: Re: Linux 2.6.34-rc3)
On Thu, 1 Apr 2010 09:29:23 -0700 (PDT)
Linus Torvalds torva...@linux-foundation.org wrote:
On Thu, 1 Apr 2010, Rafael J. Wysocki wrote:
OK, I've verified that partial revert (below) is sufficient.
Hmm. Through the DRM merge I just did, this area actually conflicted, and
the resolved version is now
if ((rdev-family = CHIP_RV380)
(!(rdev-flags RADEON_IS_IGP))) {
which presumably also fixes your issue?
[ Side note: somebody in the DRM tree seems to be way too used to LISP,
and thinks that adding parenthesis always improves the code ;-]
However, I do suspect that we should probably revert the quirk regardless
as being useless (ie it probably was related to those IGP chips that
apparently don't do MSI anyway).
So the patch that reverts the quirk by Clemens (to replace it with
disabling MSI entirely when the AMD NB doesn't accept them) seems to be a
good idea regardless, since it's apparently not just about gfx. Jesse?
Yeah, that sounds fine. I can include it in my next pull req or you
can just pick it up directly.
--
Jesse Barnes, Intel Open Source Technology Center
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/7] drm: delay vblank cleanup until after driver unload
On Mon, 29 Mar 2010 10:02:04 +1000 Dave Airlie airl...@gmail.com wrote: 2010/3/29 Kristian Høgsberg k...@bitplanet.net: On Fri, Mar 26, 2010 at 7:07 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: Drivers may use vblank calls now (e.g. drm_vblank_off) in their unload paths, so don't clean up the vblank related structures until after driver unload. I haven't tested this specific patch on a recent DRM, but I made the same patch a while ago, and it fixed module unload for me. I sent it to the list and it fell through the cracks, because vblank is hard or something. Reviewed-by: Kristian Høgsberg k...@bitplanet.net I didn't apply it because from what I can see non-kms drivers need to free the vbl stuff on lastclose not unload. I'm nearly sure I said that at the time to. This patch seems to suffer from the same problem from what I can see. And really someone should already have cleaned up the insanity that is vbl struct allocations, vblank might not be hard, but it sure has some ugly. Arg, yeah I didn't consider non-kms drivers. And we had a patch to bunch all the vbl info into a single struct, but iirc it came along as we were still adding fields so never got applied. Anyway I'll fix up this patch and re-post. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: intel graphic card hanging (Hangcheck timer elapsed... GPU hung)
On Sun, 28 Mar 2010 01:11:05 +0900 Norbert Preining prein...@logic.at wrote: Dear all, (please Cc) I am running 2.6.34-rc2 + git 01e7770 commit (yesterday) with KMS on Debian/sid: xserver-xorg: 7.5+5 video-intel: 2.9.1-3 Running D2X-xl (self compiled) (descent2 open source code) X suddenly died, and after that gdm could not be restarted because after a few secs it went dead again. In the logs I see: kernel: [ 2486.341227] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung kernel: [ 2486.341240] render error detected, EIR: 0x kernel: [ 2486.341278] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 113671 at 113604) kernel: [ 2486.669008] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung kernel: [ 2486.669012] render error detected, EIR: 0x kernel: [ 2486.669522] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 113672 at 113604) kernel: [ 2487.524230] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung kernel: [ 2487.524243] render error detected, EIR: 0x kernel: [ 2487.524284] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 113673 at 113604) kernel: [ 2487.912237] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung kernel: [ 2487.916175] render error detected, EIR: 0x kernel: [ 2487.920137] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 113674 at 113604) Stopping gdm and restarting didn't help to get the graphics card back to normal. If you have any ideas how to fix/track/debug that please let me know, same if you need more information. I was seeing something similar on my 945, can you try this patchset? It seems to make things much more stable for me. http://lists.freedesktop.org/archives/intel-gfx/2010-March/006387.html There are 7 patches starting with that one. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/7] drm: delay vblank cleanup until after driver unload
Drivers may use vblank calls now (e.g. drm_vblank_off) in their unload paths, so don't clean up the vblank related structures until after driver unload. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/drm_stub.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c index ad73e14..543e79c 100644 --- a/drivers/gpu/drm/drm_stub.c +++ b/drivers/gpu/drm/drm_stub.c @@ -515,8 +515,6 @@ void drm_put_dev(struct drm_device *dev) } driver = dev-driver; - drm_vblank_cleanup(dev); - drm_lastclose(dev); if (drm_core_has_MTRR(dev) drm_core_has_AGP(dev) @@ -536,6 +534,8 @@ void drm_put_dev(struct drm_device *dev) dev-agp = NULL; } + drm_vblank_cleanup(dev); + list_for_each_entry_safe(r_list, list_temp, dev-maplist, head) drm_rmmap(dev, r_list-map); drm_ht_remove(dev-map_hash); -- 1.6.1.3 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/7] drm: make sure vblank interrupts are disabled at DPMS time
When we call drm_vblank_off() at DPMS off time (to wake any clients so they don't hang) we need to make sure interrupts are actually disabled. If drm_vblank_off() gets called before the vblank usage timer expires, it'll prevent the timer from disabling interrupts since it also clears the vblank_enabled flag for the pipe. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/drm_irq.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index b98384d..99ce7dc 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -475,6 +475,7 @@ void drm_vblank_off(struct drm_device *dev, int crtc) unsigned long irqflags; spin_lock_irqsave(dev-vbl_lock, irqflags); + dev-driver-disable_vblank(dev, crtc); DRM_WAKEUP(dev-vbl_queue[crtc]); dev-vblank_enabled[crtc] = 0; dev-last_vblank[crtc] = dev-driver-get_vblank_counter(dev, crtc); -- 1.6.1.3 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/7] drm/i915: remove duplicate PIPE*STAT bit definitions
Just use the PIPEASTAT definitions, and kill a related, unused variable in
i915_irq_handler while we're there.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_irq.c | 23 +--
drivers/gpu/drm/i915/i915_reg.h | 26 --
2 files changed, 9 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5388354..eca0e5b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -170,7 +170,7 @@ void intel_enable_asle (struct drm_device *dev)
ironlake_enable_display_irq(dev_priv, DE_GSE);
else
i915_enable_pipestat(dev_priv, 1,
-I915_LEGACY_BLC_EVENT_ENABLE);
+PIPE_LEGACY_BLC_EVENT_ENABLE);
}
/**
@@ -832,9 +832,7 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
struct drm_i915_master_private *master_priv;
u32 iir, new_iir;
- u32 pipea_stats, pipeb_stats;
- u32 vblank_status;
- u32 vblank_enable;
+ u32 pipea_stats, pipeb_stats, pipe_vblank_mask;
int vblank = 0;
unsigned long irqflags;
int irq_received;
@@ -847,13 +845,10 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
iir = I915_READ(IIR);
- if (IS_I965G(dev)) {
- vblank_status = I915_START_VBLANK_INTERRUPT_STATUS;
- vblank_enable = PIPE_START_VBLANK_INTERRUPT_ENABLE;
- } else {
- vblank_status = I915_VBLANK_INTERRUPT_STATUS;
- vblank_enable = I915_VBLANK_INTERRUPT_ENABLE;
- }
+ if (IS_I965G(dev))
+ pipe_vblank_mask = PIPE_START_VBLANK_INTERRUPT_STATUS;
+ else
+ pipe_vblank_mask = PIPE_VBLANK_INTERRUPT_STATUS;
for (;;) {
irq_received = iir != 0;
@@ -933,19 +928,19 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
if (iir I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT)
intel_prepare_page_flip(dev, 1);
- if (pipea_stats vblank_status) {
+ if (pipea_stats pipe_vblank_mask) {
vblank++;
drm_handle_vblank(dev, 0);
intel_finish_page_flip(dev, 0);
}
- if (pipeb_stats vblank_status) {
+ if (pipeb_stats pipe_vblank_mask) {
vblank++;
drm_handle_vblank(dev, 1);
intel_finish_page_flip(dev, 1);
}
- if ((pipeb_stats I915_LEGACY_BLC_EVENT_STATUS) ||
+ if ((pipeb_stats PIPE_LEGACY_BLC_EVENT_STATUS) ||
(iir I915_ASLE_INTERRUPT))
opregion_asle_intr(dev);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2720bc2..df20187 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -486,32 +486,6 @@
#define DPLL_FPA01_P1_POST_DIV_MASK 0x00ff /* i915 */
#define DPLL_FPA01_P1_POST_DIV_MASK_PINEVIEW 0x00ff8000 /* Pineview */
-#define I915_FIFO_UNDERRUN_STATUS (1UL31)
-#define I915_CRC_ERROR_ENABLE (1UL29)
-#define I915_CRC_DONE_ENABLE (1UL28)
-#define I915_GMBUS_EVENT_ENABLE(1UL27)
-#define I915_VSYNC_INTERRUPT_ENABLE(1UL25)
-#define I915_DISPLAY_LINE_COMPARE_ENABLE (1UL24)
-#define I915_DPST_EVENT_ENABLE (1UL23)
-#define I915_LEGACY_BLC_EVENT_ENABLE (1UL22)
-#define I915_ODD_FIELD_INTERRUPT_ENABLE(1UL21)
-#define I915_EVEN_FIELD_INTERRUPT_ENABLE (1UL20)
-#define I915_START_VBLANK_INTERRUPT_ENABLE (1UL18) /* 965 or later
*/
-#define I915_VBLANK_INTERRUPT_ENABLE (1UL17)
-#define I915_OVERLAY_UPDATED_ENABLE(1UL16)
-#define I915_CRC_ERROR_INTERRUPT_STATUS(1UL13)
-#define I915_CRC_DONE_INTERRUPT_STATUS (1UL12)
-#define I915_GMBUS_INTERRUPT_STATUS(1UL11)
-#define I915_VSYNC_INTERRUPT_STATUS(1UL9)
-#define I915_DISPLAY_LINE_COMPARE_STATUS (1UL8)
-#define I915_DPST_EVENT_STATUS (1UL7)
-#define I915_LEGACY_BLC_EVENT_STATUS (1UL6)
-#define I915_ODD_FIELD_INTERRUPT_STATUS(1UL5)
-#define I915_EVEN_FIELD_INTERRUPT_STATUS (1UL4)
-#define I915_START_VBLANK_INTERRUPT_STATUS (1UL2)/* 965 or later
*/
-#define I915_VBLANK_INTERRUPT_STATUS (1UL1)
-#define I915_OVERLAY_UPDATED_STATUS(1UL0)
-
#define SRX_INDEX 0x3c4
#define SRX_DATA 0x3c5
#define SR01 1
--
1.6.1.3
--
Download Intel
[PATCH 4/7] drm/i915: only check for enabled PIPE*STAT interrupts
Most of the PIPE*STAT status bits will continue to flip even if they're
not generating interrupts. So only check for those that can cause
interrupts when we reach the i915_irq_handler, since it might be shared
and we don't want to process spurious events.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c |6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index aba8260..abf2713 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -260,6 +260,7 @@ typedef struct drm_i915_private {
/** Cached value of IMR to avoid reads in updating the bitfield */
u32 irq_mask_reg;
u32 pipestat[2];
+ u32 pipe_mask[2];
/** splitted irq regs for graphics and display engine on Ironlake,
irq_mask_reg is still used for display irq. */
u32 gt_irq_mask_reg;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eca0e5b..9519346 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -141,6 +141,7 @@ i915_enable_pipestat(drm_i915_private_t *dev_priv, int
pipe, u32 mask)
u32 reg = i915_pipestat(pipe);
dev_priv-pipestat[pipe] |= mask;
+ dev_priv-pipe_mask[pipe] |= (mask 16);
/* Enable the interrupt, clear any pending status */
I915_WRITE(reg, dev_priv-pipestat[pipe] | (mask 16));
(void) I915_READ(reg);
@@ -154,6 +155,7 @@ i915_disable_pipestat(drm_i915_private_t *dev_priv, int
pipe, u32 mask)
u32 reg = i915_pipestat(pipe);
dev_priv-pipestat[pipe] = ~mask;
+ dev_priv-pipe_mask[pipe] = ~(mask 16);
I915_WRITE(reg, dev_priv-pipestat[pipe]);
(void) I915_READ(reg);
}
@@ -868,14 +870,14 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
/*
* Clear the PIPE(A|B)STAT regs before the IIR
*/
- if (pipea_stats 0x8000) {
+ if (pipea_stats dev_priv-pipe_mask[0]) {
if (pipea_stats PIPE_FIFO_UNDERRUN_STATUS)
DRM_DEBUG_DRIVER(pipe a underrun\n);
I915_WRITE(PIPEASTAT, pipea_stats);
irq_received = 1;
}
- if (pipeb_stats 0x8000) {
+ if (pipeb_stats dev_priv-pipe_mask[1]) {
if (pipeb_stats PIPE_FIFO_UNDERRUN_STATUS)
DRM_DEBUG_DRIVER(pipe b underrun\n);
I915_WRITE(PIPEBSTAT, pipeb_stats);
--
1.6.1.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 5/7] drm/i915: use vblank and vsync interrupts on 945
On 945, vblank delivery alone seems unreliable. The PIPE*STAT bits get set correctly, but interrupts occur at a low frequency relative to refresh. If we enable VSYNC interrupts as well however (even though we only check for VBLANK interrupts when handling) we get the right frequency. Increases OA performance on my AspireOne by about 300% with the new DRI2 bits, which rely on high frequency vblank events. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_irq.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 9519346..b16bb0d 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -45,8 +45,8 @@ */ #define I915_INTERRUPT_ENABLE_FIX \ (I915_ASLE_INTERRUPT | \ -I915_DISPLAY_PIPE_A_EVENT_INTERRUPT | \ -I915_DISPLAY_PIPE_B_EVENT_INTERRUPT | \ +I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT | \ +I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT | \ I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT | \ I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT | \ I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT) @@ -1132,6 +1132,7 @@ int i915_enable_vblank(struct drm_device *dev, int pipe) PIPE_START_VBLANK_INTERRUPT_ENABLE); else i915_enable_pipestat(dev_priv, pipe, +PIPE_VSYNC_INTERRUPT_ENABLE | PIPE_VBLANK_INTERRUPT_ENABLE); spin_unlock_irqrestore(dev_priv-user_irq_lock, irqflags); return 0; @@ -1151,6 +1152,7 @@ void i915_disable_vblank(struct drm_device *dev, int pipe) DE_PIPEA_VBLANK: DE_PIPEB_VBLANK); else i915_disable_pipestat(dev_priv, pipe, + PIPE_VSYNC_INTERRUPT_ENABLE | PIPE_VBLANK_INTERRUPT_ENABLE | PIPE_START_VBLANK_INTERRUPT_ENABLE); spin_unlock_irqrestore(dev_priv-user_irq_lock, irqflags); -- 1.6.1.3 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 7/7] drm/i915: cleanup mode setting before unmapping registers
We'll turn off outputs etc at unload time, so don't unmap the registers
before doing it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 193bf16..91a3c3d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1760,6 +1760,8 @@ int i915_driver_unload(struct drm_device *dev)
}
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
+ intel_modeset_cleanup(dev);
+
/*
* free the memory space allocated for the child device
* config parsed from VBT
@@ -1783,8 +1785,6 @@ int i915_driver_unload(struct drm_device *dev)
intel_opregion_free(dev, 0);
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
- intel_modeset_cleanup(dev);
-
i915_gem_free_all_phys_object(dev);
mutex_lock(dev-struct_mutex);
--
1.6.1.3
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 4/7] drm/i915: only check for enabled PIPE*STAT interrupts
On Fri, 26 Mar 2010 11:07:18 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
Most of the PIPE*STAT status bits will continue to flip even if they're
not generating interrupts. So only check for those that can cause
interrupts when we reach the i915_irq_handler, since it might be shared
and we don't want to process spurious events.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c |6 --
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index aba8260..abf2713 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -260,6 +260,7 @@ typedef struct drm_i915_private {
/** Cached value of IMR to avoid reads in updating the bitfield */
u32 irq_mask_reg;
u32 pipestat[2];
+ u32 pipe_mask[2];
/** splitted irq regs for graphics and display engine on Ironlake,
irq_mask_reg is still used for display irq. */
u32 gt_irq_mask_reg;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index eca0e5b..9519346 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -141,6 +141,7 @@ i915_enable_pipestat(drm_i915_private_t *dev_priv, int
pipe, u32 mask)
u32 reg = i915_pipestat(pipe);
dev_priv-pipestat[pipe] |= mask;
+ dev_priv-pipe_mask[pipe] |= (mask 16);
/* Enable the interrupt, clear any pending status */
I915_WRITE(reg, dev_priv-pipestat[pipe] | (mask 16));
(void) I915_READ(reg);
@@ -154,6 +155,7 @@ i915_disable_pipestat(drm_i915_private_t *dev_priv, int
pipe, u32 mask)
u32 reg = i915_pipestat(pipe);
dev_priv-pipestat[pipe] = ~mask;
+ dev_priv-pipe_mask[pipe] = ~(mask 16);
I915_WRITE(reg, dev_priv-pipestat[pipe]);
(void) I915_READ(reg);
}
@@ -868,14 +870,14 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
/*
* Clear the PIPE(A|B)STAT regs before the IIR
*/
- if (pipea_stats 0x8000) {
+ if (pipea_stats dev_priv-pipe_mask[0]) {
if (pipea_stats PIPE_FIFO_UNDERRUN_STATUS)
DRM_DEBUG_DRIVER(pipe a underrun\n);
I915_WRITE(PIPEASTAT, pipea_stats);
irq_received = 1;
}
- if (pipeb_stats 0x8000) {
+ if (pipeb_stats dev_priv-pipe_mask[1]) {
if (pipeb_stats PIPE_FIFO_UNDERRUN_STATUS)
DRM_DEBUG_DRIVER(pipe b underrun\n);
I915_WRITE(PIPEBSTAT, pipeb_stats);
Still testing 4-6 on GM45 to make sure I haven't broken anything on
non-gen3, additional testing would be appreciated too. These core
changes always make me nervous.
--
Jesse Barnes, Intel Open Source Technology Center
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 6/7] drm/i915: fix page flipping on gen3
On Fri, 26 Mar 2010 11:07:20 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
- if (iir I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT)
+ if ((iir I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT)
+ !(pipeb_stats pipe_vblank_mask)) {
+ DRM_ERROR(flip complete w/o vblank irq?\n);
+ }
Oops, this hunk definitely doesn't belong here. I'll post an update to
this one.
--
Jesse Barnes, Intel Open Source Technology Center
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, 4 Mar 2010 15:20:46 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 05 Mar 2010 00:16:45 +0100 Michel Dänzer mic...@daenzer.net wrote: On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. Ditto for dri-devel. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? Not really, the lists should still have their own admins. I've been going through the moderation queues for both lists on a daily basis and am volunteering to continue doing so, but other than that I'm not really keen on being a list admin. I don't have access to create the new lists, but Daniel or Tollef should. We may as well keep you guys as admins unless someone volunteers that you're ok with; but hopefully FDO will make the admin job a little easier/faster. Brian and Michel, did you guys get what you need to move the lists? AFAIK Tollef created them, you just need to copy the subscriber lists over and announce it I think? Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] PCI quirks: RS780/RS880: work around missing MSI initialization
On Mon, 22 Mar 2010 12:28:00 -0400 Alex Deucher alexdeuc...@gmail.com wrote: On Mon, Mar 22, 2010 at 4:52 AM, Clemens Ladisch clem...@ladisch.de wrote: AMD says in section 2.5.4 (GFX MSI Enable) of #43291 (AMD 780G Family Register Programming Requirements): The SBIOS must enable internal graphics MSI capability in GCCFG by setting the following: NBCFG.NB_CNTL.STRAP_MSI_ENABLE='1' Quite a few BIOS writers misinterpret this sentence and think that enabling MSI is an optional feature. However, clearing that bit just prevents delivery of MSI messages but does not remove the MSI PCI capabilities registers, and so leaves these devices unusable for any driver that attempts to use MSI. Setting that bit is not possible after the BIOS has locked down the configuration registers, so we have to manually disable MSI for the affected devices. This fixes the codec communication errors in the HDA driver when accessing the HDMI audio device, and allows us to get rid of the overcautious quirk in radeon_irq_kms.c. Looks good. This works properly on my rs780. Tested-by: Alex Deucher alexdeuc...@gamil.com Great, applied to my for-linus branch. I'll send it over to Linus this week. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ACPI _LID failures
On Fri, 19 Mar 2010 13:53:10 -0700 Eric Anholt e...@anholt.net wrote: On Fri, 19 Mar 2010 12:53:20 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 15 Mar 2010 21:32:41 +0200 Surbhi Palande surbhi.pala...@canonical.com wrote: The following two patches are quirks that blacklist bios which report incorrect lid status. These are bioses for machines with a 900 GM. The first one is tested by Ubuntu users and the second one isn't. Further testing will be appreciated. Surbhi Palande (2): drm/i915: blacklist lid status: Sony VGN-BX196VP drm/i915: blacklist lid status: Elite Co. G335 drivers/gpu/drm/i915/intel_lvds.c | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) Patches look ok to me. Len was curious about whether some recent ACPI EC fixes will fix some of our lid detection bugs though. Len, is there any particular patch or version people should try? Unless ACPI is going to magically become more reliable at the lid method, I think we should abandon using it on generations where it fails. See other patch I submitted -- anyone care to ack it? Well, that was the hope. Len said they've fixed EC bugs in the past only to find that several ACPI methods they assumed were broken suddenly started working -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
It would help to know what the server is doing at this point with the client. It may be that it put the client to sleep and hasn't woken it up yet, or there could be something wrong with our getbuffers code in the new scheme. Jesse On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue mailingli...@openelec.tv wrote: looks this like my problems that i have reported some days ago with Subject Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?) to Mesa-dev, xorg and intel-gfx list? i have still this issue, but i dont know what you need for informations to fix the issues? with ati driver i dont have problems, only here with intel driver on my Thinkpad X200t with intel HDA Graphics card Stephan Am 06.03.2010 17:46, schrieb Maxim Levitsky: On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. Here, gdb backtrace while running sauerbraten full screen: #2 0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1 #3 0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #4 0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454 #5 0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, outCount=0xbfc6a608) at dri2.c:428 #6 0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608, loaderPrivate=0x93eecb0) at dri2_glx.c:435 #7 0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253 #8 0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395 #9 0xb657a423 in brw_try_draw_prims (ctx=value optimized out, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at brw_draw.c:340 #10 brw_draw_prims (ctx=value optimized out, arrays
Re: [git pull] drm request 3
On Fri, 5 Mar 2010 08:44:07 +0100 Ingo Molnar mi...@elte.hu wrote: It's a bit as if we split up the kernel into 'microkernel' components, did a VFS ABI, MM ABI, drivers ABI, scheduler ABI, networking ABI and arch ABIs, and then tried to develop them as separate components. If we did then then Linux kernel development would slow down massively while in reality everyone would _still_ have to have the latest and greatest source checked out to do some real development work and to be able to implement features that affect the whole kernel ... Linux would become an epic fail of historic proportions if we ever did that. This is a very good point, and something we've been wrestling with in the gfx community. Awhile back we separated the X drivers from the X core; I feel this was a mistake for the reasons you mention above. It's just plain harder to fix issues when you have to rev the ABI with every change, make sure both the old/new and new/old combinations work, and generally improve things like we do inside of Linux. [*] I realize that it's possibly hard for Xorg to merge with mesa and the kernel for license reasons, but my technical observation still stands. No we don't need to merge them fortunately. With GEM and KMS we've pushed two major bits of functionality into the kernel; bits that were badly split between all portions of the stack before. With EGL, we can push a lot of what X did into Mesa. There are even some projects to make a very thin X driver or separate display server sit directly on top of Mesa + EGL, unifying things further. So I really think things are getting better here, not worse (the nouveau issue here aside). -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test (was Re: [git pull] drm request 3)
On Fri, 5 Mar 2010 07:53:46 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Fri, 5 Mar 2010, Carlos R. Mafra wrote: Whereas everytime I wanted to do that with Xorg it was such a pain that I want to keep away from that mess. Actually, take it from me: Xorg is _pleasant_ to test these days. Ok, so that's partly compared to the mess it _used_ to be, but it's really night and day. The whole build system was so incredibly baroque and heavy that you really had to understand it deeply if you wanted to do anything fancy. And the non-fancy alternative was to just build the whole thing, which took _hours_ even on fast machines because the build system overhead was near-infinite (I dunno, maybe parallel builds could be made to work, but it took more brain-power than I could ever put into it). These days, there's a few dependencies you need to know about (I do agree that from a user perspective the thing might have been made a bit _too_ modular) but they are generally fairly trivial, and there are scripts to download all the drivers and misc utilities needed. Just FYI for those following this thread; testing the server and 3D drivers really isn't too much trouble these days, you can even install everything into a separate path (I usually choose /opt-gfx-test); you just need to build libdrm, mesa, xserver and your video driver (along with an input driver or tw) in that order. Then just startx -- /opt/gfx-test/bin/Xorg and put something reasonable in .xinitrc. Full instructions at http://wiki.x.org/wiki/Development/BuildingX. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
On Fri, 05 Mar 2010 09:54:06 -0800 (PST) David Miller da...@davemloft.net wrote: From: Xavier Bestel xavier.bes...@free.fr Date: Fri, 05 Mar 2010 18:50:24 +0100 On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:41:43 +0200 I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. You have to support less than %10 of the amount of hardware we have to support. You can't compare a network card and a GPU. The latter is way more complex to code for. I wasn't talking specifically about network cards. But if you want specific examples... How about the x86 or parisc cpu, and all their derivatives, are those complex enough for you? :-) I've worked on OpenGL capable grapics card drivers of various vintages, and I honestly don't think there is anything in there more complex than what we have to deal with in the kernel. I think you must be saying this for the sake of argument. The complexity lies not in the programming interfaces exposed by the device (those indeed are complex, more so than some CPUs, less so than others). The complexity lies in the fact that those interfaces change from revision to revision, and even between boards sharing the same chip. And more than that, the interfaces exposed to applications are spread across many software components, some of which send commands to the hardware directly. The problem Linus ran into is directly related to this fact, because it involved the interfaces between a few of these components. So from that perspective, the graphics stack is the most complex one in Linux by a long shot. It's even worse than if we had STREAMS networking with a ton of different modules up in userspace messing with protocol. :) -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] i965 OpenGL is heavily broken again
On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Now I repeat same process and find out that OpenGL does work, but once again it became very buggy, so buggy that it is almost unusable. Neverball. - Now it hangs when I switch to full screen mode. - Also, once again frames appear to be rendered in batches In fact full screen mode leads to a hang always Sauerbraten. - Hangs early with 'Loading' Nexuiz - Same as above Compiz. - Hangs now after start GoogleEarth - No change, works, but in street view, one on screen label 'jumps' Xmoto, Torcs. Full screen mode hangs. I just pushed a few fixes to the xf86-video-intel code that might help... -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] i965 OpenGL is heavily broken again
On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I now compiled same stack, but reverted mesa to commit 465fee75ee8991349da742e5a1a5be3cd179bb62 Author: Roland Scheidegger srol...@vmware.com Date: Sat Nov 21 04:39:30 2009 -0800 intel: make CopyTex[Sub]Image fallback debug messages more consistent And compiled the xserver with --disable-aiglx (I will always use that option from now on, because I hate the way X and mesa are tied otherwise. For example X won't build if I compile it against old mesa, etc...) If you can't get AIGLX to work then it may indicate a bigger problem. X needs to load a DRI driver to perform acceleration for indirect clients, I'm not sure what in that is hate-worthy. And now all 3D problems are gone. I now doing a bisect, although I am not sure if it will help much. Probably not. It sounds like your configuration is pretty custom and something is seriously broken, so it'll be hard to help further. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Move lists to freedesktop.org?
On Fri, 5 Mar 2010 23:19:13 +0100 olafbuddenha...@gmx.net wrote: Hi, On Thu, Mar 04, 2010 at 12:37:23PM -0800, Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, Err, how would moving the list to fdo help with the non-subscriber aspect?... I was thinking that managing the moderation queue would be faster; sf.net is always horribly slow for me, but fdo is usually pretty quick. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Remove the EDID blob stored in the EDID property when it is disconnected
On Thu, 4 Mar 2010 16:25:55 +0800
Zhenyu Wang zhen...@linux.intel.com wrote:
From: Zhao Yakui yakui.z...@intel.com
Now the EDID property will be updated when the corresponding EDID can be
obtained from the external display device. But after the external device
is plugged-out, the EDID property is not updated. In such case we still
get the corresponding EDID property although it is already detected as
disconnected.
https://bugs.freedesktop.org/show_bug.cgi?id=26743
Signed-off-by: Zhao Yakui yakui.z...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/drm_crtc_helper.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index f2aaf39..51103aa 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -104,6 +104,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
if (connector-status == connector_status_disconnected) {
DRM_DEBUG_KMS(%s is disconnected\n,
drm_get_connector_name(connector));
+ drm_mode_connector_update_edid_property(connector, NULL);
goto prune;
}
I think this should be safe, and does fix a real bug. If so, it should
also be cc: sta...@kernel.org.
Dave?
--
Jesse Barnes, Intel Open Source Technology Center
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 10:51:20 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Jesse Barnes wrote: On Thu, 4 Mar 2010 10:36:55 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... And now I see Dave did mention this, so what gives. Guidance please. Yeah, it's in the first one. My bad. I didn't notice, because that one got cancelled for other reasons and never even tested. That doesn't change the simple basic issue: how are people with Fedora-12 going to test any kernel out now? And are there libdrm versions that can handle _both_ cases, so that people can bisect things? IOW, even if you have a new libdrm, will it then work with the _old_ kernel too? Backwards compatibility is really important. Sure it is. But OTOH this is very clearly a use at your own risk driver. Dave and the nouveau guys include the driver in Fedora to get much needed test coverage, and make sure the latest bits in rawhide work together. The use at your own risk part is that you get to keep both pieces if you try to mix and match kernels and userspace until the STAGING moniker is removed. If marking the driver as staging doesn't allow them to break ABI when they need to, then it seems like they'll have no choice but to either remove the driver from upstream and only submit it when the ABI is stable, or fork the driver and submit a new one only when the ABI is stable. Neither seem particularly attractive. Of course I'm implicitly trusting their motivation for breaking ABI in this case, but that was very much a part of the merge discussion so shouldn't come as a surprise to anyone. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 10:18:03 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: Hmm. What the hell am I supposed to do about (II) NOUVEAU(0): [drm] nouveau interface version: 0.0.16 (EE) NOUVEAU(0): [drm] wrong version, expecting 0.0.15 (EE) NOUVEAU(0): 879: now? What happened to the whole backwards compatibility thing? I wasn't even warned that this breaks existing user space. That makes it impossible to _test_ new kernels. Upgrading X and the kernel in lock-step is not a valid model, lots of people are just using some random distribution (F12 in my case), and you just broke it. I see the commit that does this was very aware of it: commit a1606a9596e54da90ad6209071b357a4c1b0fa82 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 12 10:27:35 2010 +1000 drm/nouveau: new gem pushbuf interface, bump to 0.0.16 This commit breaks the userspace interface, and requires a new libdrm for nouveau to operate again. The multiple GEM_PUSHBUF ioctls that were present in 0.0.15 for compatibility purposes are now gone, and replaced with the new ioctl which allows for multiple push buffers to be submitted (necessary for hw index buffers in the nv50 3d driver) and relocations to be applied on any buffer. A number of other ioctls (CARD_INIT, GEM_PIN, GEM_UNPIN) that were needed for userspace modesetting have also been removed. Signed-off-by: Ben Skeggs bske...@redhat.com Signed-off-by: Francisco Jerez curroje...@riseup.net but why the hell wasn't I made aware of it before-hand? Quite frankly, I probably wouldn't have pulled it. We can't just go around breaking peoples setups. This driver is, like it or not, used by Fedora-12 (and probably other distros). It may say staging, but that doesn't change the fact that it's in production use by huge distributions. Flag days aren't acceptable. Whoa, so breaking ABI in staging drivers isn't ok? Lots of other staging drivers are shipped by distros with compatible userspaces, but I thought the whole point of staging was to fix up ABIs before they became mainstream and had backwards compat guarantees, meaning that breakage was to be expected? Yes, it sucks, but what else should the nouveau developers have done? They didn't want to push nouveau into mainline because they weren't happy with the ABI yet, but it ended up getting pushed anyway as a staging driver at your request, and now they're stuck? Sorry this whole thing is a bit of a wtf... Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 10:36:55 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: Yes Dave probably should have mentioned it in his pull request, but that doesn't seem to be a good reason not to pull imo... And now I see Dave did mention this, so what gives. Guidance please. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 11:08:07 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: The thing is, they clearly didn't even _try_ to make anything compatible. See how all the ioctl numbers were moved around. And if you can't make if backwards compatible, at least you should make it forwards-compatible. Is it even that? I don't know. I'm kind of afraid it isn't. The new libdrm required for it certainly hasn't been pushed to Fedora-12. Will it ever be? And if it is, can you still run an old kernel on it? Sure, but both kinds of compat come at a cost, a potentially large one in this case, so why take it on before absolutely necessary? I know you can see both sides of this... And btw, I'd complain about breaking backwards compatibility even if it wasn't just my own machine. I can pretty much guarantee that I'm not going to be the only one hitting this issue. Right, but OTOH it's a development driver. If you're running Fedora, things will work as long as you stick to the distro packages. And if you're building your own kernels, you ought to be taking care with staging drivers, right? So practically speaking: what _do_ you suggest we do about all the regressions this will cause? Before this thread I thought the policy was let people muddle through with staging drivers until their staging status is cleared. If that's not the case, then really what's the point of staging? I'm sure there are other examples of this type of breakage in staging drivers, though admittedly nouveau is probably the biggest in terms of user interest. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Move lists to freedesktop.org?
Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Thu, 4 Mar 2010 14:54:03 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Thu, 4 Mar 2010, Stephane Marchesin wrote: In short, the don't break user space interfaces principle is making user space code quality worse for everyone. And it makes our lives as graphics developers pretty miserable actually And _my_ point is that if you did a half-way decent job on versioning, you wouldn't be in the crappy situation you are now. For chissake, the DRM versioning model is a total disaster. The reason you can never ever break user space interfaces is exactly because when you break them, X stops working. What I suggested is to _keep_ a working model across different versions, so that you can get out of the rat-hole you are in now (and the rat-hole you put your users into, and the distributions). It's simply _not_ acceptable to tie the X server and the kernel version so tightly together as the crazy DRM model does right now. It's not all that different from us requiring people to install a new glibc every once in a while, just because we added a new filesystem. Everybody understands that that would be totally insane. Why does the X community not understand simple library versioning? We use versioning on the Intel side, but in the form of feature flags as new things are added (we've had a handful since GEM was added in 2.6.28). It's a pain to handle the various code paths, but no more so than having lots of separate library versions to support. That would be nice from one perspective, but it would only save work if we abandoned the old versions quickly and kept a big shared component between library versions. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, 4 Mar 2010 14:55:29 -0800 Dan Nicholson dbn.li...@gmail.com wrote: On Thu, Mar 4, 2010 at 2:42 PM, Eric Anholt e...@anholt.net wrote: On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. sf.net's mail interface is made of fail. Here's to changing to something credible. The funny thing about it is they're clearly using mailman, which has an archives interface, but they felt the need to implement some dog slow php forum-like interface over it. Why? And their delivery is really slow too, which is quite annoying for active discussions. I guess Brian or Michel could get the current subscriber lists and transfer them over once we have the new lists. -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Fri, 05 Mar 2010 00:16:45 +0100 Michel Dänzer mic...@daenzer.net wrote: On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: Jesse Barnes wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. Jesse, can you set up the new lists? Or does someone else need to do that? I can send you (or whoever) the current subscriber lists. Ditto for dri-devel. BTW, I'm the current admin for the Mesa lists on SourceForge. I manually unsubscribe people who can't figure it out for themselves, allow posts from non-members (sometimes), etc. I'd gladly pass on that responsibility to someone else. Would that automatically become the job of the current fd.o admins? Not really, the lists should still have their own admins. I've been going through the moderation queues for both lists on a daily basis and am volunteering to continue doing so, but other than that I'm not really keen on being a list admin. I don't have access to create the new lists, but Daniel or Tollef should. We may as well keep you guys as admins unless someone volunteers that you're ok with; but hopefully FDO will make the admin job a little easier/faster. Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bugme-new] [Bug 15248] New: KMS broken on Intel 855GM broken with 2.6.32/33
On Tue, 9 Feb 2010 13:23:50 +0100 Rafael J. Wysocki r...@sisk.pl wrote: On Tuesday 09 February 2010, Andrew Morton wrote: On Sun, 7 Feb 2010 09:59:06 GMT bugzilla-dae...@bugzilla.kernel.org wrote: http://bugzilla.kernel.org/show_bug.cgi?id=15248 DRI/KMS regression #1,987,776 Added, CCing dri-devel and the i915 maintainers. Hey now, I only count 10 that look KMS related, that's a lot fewer than 1,987,776. Better yet, 6 or so have fixes now, and the other ones are getting looked at. So there. -- Jesse Barnes, Intel Open Source Technology Center -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bug #15043] Display goes off with i915.powersave=1 after suspend-resume
On Thu, 4 Feb 2010 21:42:02 +0100 Rafael J. Wysocki r...@sisk.pl wrote: On Thursday 04 February 2010, Soeren Sonnenburg wrote: On Mon, 2010-02-01 at 01:22 +0100, Rafael J. Wysocki wrote: This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15043 Subject : Display goes off with i915.powersave=1 after suspend-resume Submitter: Soeren Sonnenburg so...@debian.org Date : 2010-01-10 20:09 (22 days old) References : http://marc.info/?l=linux-kernelm=126315457519505w=4 yes still exists in current git. Thanks for the update. Just updated the corresponding FDO bug (https://bugs.freedesktop.org/show_bug.cgi?id=24314). There are some hw bugs related to FBC handling on 945GM though, so we may have to disable it on some machines. -- Jesse Barnes, Intel Open Source Technology Center -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Thu, 4 Feb 2010 20:32:32 +0100 Ingo Molnar mi...@elte.hu wrote: Nobody has reacted to my related boot hang bugreport yet - and it's detailed and fully reproducible (so i can test any proposed fixes as well in short order). I.e. my limited testing has triggered two separate bugs in the same driver - and this will show up in -rc7. It might be all OK and no-one else will see trouble. Or past patterns might repeat themselves and i might simply be an early bird for trouble to come. My (oft repeated) point is that adding new sub-features to existing drivers is not what we do in late -rc's: there's simply not enough time to shake out bugs/regressions in them. We introduce new functionality to existing drivers in the merge window - in the two weeks following a stable kernel's release. This is the .config issue right? It doesn't sound like the bug is new, you're just seeing now it because of the way you run tests. It shouldn't affect any more or fewer users than it did before, and reverting the move radeon KMS out of staging won't fix the bug at all or prevent anyone from seeing it. People using KMS will still use KMS and people without it won't, because no one actually uses allyes configs, and the option defaults to N anyway. In late -rc's we only try to fix regressions. Sometimes we make exceptions for pragmatic reasons, but then we are straightforward about those reasons and try to warn users about our zeal to help them with cool, new, not-to-be-missed GPU functionality ;-) Agree, I just don't think this is a regression or an exception. -- Jesse Barnes, Intel Open Source Technology Center -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Add a generic function to change connector type/id of connector dynamically
On Wed, 27 Jan 2010 19:25:04 +1000 Dave Airlie airl...@redhat.com wrote: On Wed, 2010-01-27 at 15:16 +0800, yakui.z...@intel.com wrote: From: Zhao Yakui yakui.z...@intel.com Sometimes one connector can support more than one connector type. And it will switch the connector type/id dynamically according to the external connected device. Connectors cannot change they physical plugs that users plug stuff into. Yakui, I think what we really want here is to split the SDVO code (at the very least) into an encoder/connector scheme like radeon uses. Most of the Intel outputs have paired encoder/connectors (e.g. LVDS, TV, VGA) but SDVO doesn't, so we should split it out. The fact that it's still treated as a single blob is historical, dating back from the big rework Dave did to properly split encoders from connectors. -- Jesse Barnes, Intel Open Source Technology Center -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] PM / i915: Skip kernel VT switch during suspend/resume if KMS is used
On Sun, 24 Jan 2010 00:55:59 +0100 Rafael J. Wysocki r...@sisk.pl wrote: From: Rafael J. Wysocki r...@sisk.pl If a non-KMS graphics driver is used, the kernel carries out a VT switch during suspend/resume to avoid possible problems with freezing X at a wrong time and to cause X to repaint everything after resume. This is not necessary any more if the KMS is used, so skip the kernel VT switch during suspend/resume for i915 in the KMS mode. Signed-off-by: Rafael J. Wysocki r...@sisk.pl --- Hi, I've been testing this patch for over a week and haven't seen a single problem related to it during this time. Are there any objections to it? This probably belongs in the core DRM KMS code instead of the driver. I can imagine that there may be some X driver code that still needs to be executed on suspend/resume for some drivers, so this may introduce bugs, but it's definitely the right way to go. Dave? -- Jesse Barnes, Intel Open Source Technology Center -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] PM / i915: Skip kernel VT switch during suspend/resume if KMS is used
On Mon, 25 Jan 2010 18:43:50 + Alan Cox a...@lxorguk.ukuu.org.uk wrote: This probably belongs in the core DRM KMS code instead of the driver. I can imagine that there may be some X driver code that still needs to be executed on suspend/resume for some drivers, so this may introduce bugs, but it's definitely the right way to go. You can have a mix of KMS and non KMS consoles active on different cards. So I don't think that is the case. I pity users with that configuration. But in that case we should be able to disable the VT switch disable path; we just have to check each driver as it's loaded. -- Jesse Barnes, Intel Open Source Technology Center -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Bugme-new] [Bug 15046] New: Flicker on laptop monitor
On Thu, 14 Jan 2010 21:04:55 +0100 Rafael J. Wysocki r...@sisk.pl wrote: On Thursday 14 January 2010, Andrew Morton wrote: On Mon, 11 Jan 2010 11:49:17 GMT bugzilla-dae...@bugzilla.kernel.org wrote: http://bugzilla.kernel.org/show_bug.cgi?id=15046 2.6.31 - 2.6.32 DRM regression. This is getting awful. Well, I wonder how many of them are dups. Quite a few of them are, afaik. I just sent a patch for what seems to be the most common one... -- Jesse Barnes, Intel Open Source Technology Center -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
On Tue, 12 Jan 2010 17:28:33 + (GMT) James Simmons jsimm...@infradead.org wrote: On 01/07/2010 12:42 AM, Johan Hovold wrote: Yeap. The fix uncovered a bug in your driver. I haven't heard of problems with the other drm drivers. The backlight is handled via the DRI driver I assume. At least i9xx_crtc_dpms is called on powerdown. Can you post your dmesg and kernel config. [snip] Adding the Intel DRM people in CC as well. I have the same issue with my GM45. Okay I looked at the code to figure out what is happening and why only this driver has problems. The problem is that the framebuffer layer expects the backlight to be a seperate device. The reason being is that some embedded systems will use a gpio backlight. That way power management for a graphics card/backlight has 3 seperate states. Currently the intel DRM driver treats the backlight as being apart of the encoder. Jesse do you have objections to having the intel driver expose a backlight device. The bonus of that is the user can also set the backlight levels. On Intel we usually expect the backlight to be exposed by ACPI or a platform driver. On recent platforms, the ACPI driver will actually send requests to the gfx driver to do the actual register writes to adjust the backlight, but it's still ACPI driven. Maybe we just need to wire up the fb backlight hooks appropriately? -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [Mesa3d-dev] [git] Support for new DRI2 protocol
On Fri, 8 Jan 2010 12:00:47 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: DRI2 now has support for swapbuffers, OML_sync_control and events. There's a git tree at git://people.freedesktop.org/~jbarnes/mesa with support for the new requests that I'd like to push into Mesa master. Can people take a look at make sure I don't have anything horribly wrong? I've tested it against both old and new X servers (that is, servers with and w/o support for the new requests) and things seem solid, so I think it's ready to go. Building does require current dri2proto bits (all of which are in dri2proto master); I should probably spin a release of that just to make things easy. I pushed into master after Jakob and Kristian had a look yesterday. I had to push a small fix afterward: mesa's autoconf wasn't checking for the glproto version, but now that we require 1.4.11 to build I added a check for it. The pull also included a check for dri2proto 2.2, which is required as well. -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [Mesa3d-dev] [git] Support for new DRI2 protocol
On Tue, 12 Jan 2010 17:37:35 -0800 Dan Nicholson dbn.li...@gmail.com wrote: On Tue, Jan 12, 2010 at 10:21 AM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 8 Jan 2010 12:00:47 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: DRI2 now has support for swapbuffers, OML_sync_control and events. There's a git tree at git://people.freedesktop.org/~jbarnes/mesa with support for the new requests that I'd like to push into Mesa master. Can people take a look at make sure I don't have anything horribly wrong? I've tested it against both old and new X servers (that is, servers with and w/o support for the new requests) and things seem solid, so I think it's ready to go. Building does require current dri2proto bits (all of which are in dri2proto master); I should probably spin a release of that just to make things easy. I pushed into master after Jakob and Kristian had a look yesterday. I had to push a small fix afterward: mesa's autoconf wasn't checking for the glproto version, but now that we require 1.4.11 to build I added a check for it. The pull also included a check for dri2proto 2.2, which is required as well. Jesse, for the glproto check, I think it should be folded into the DRI2PROTO pkg-config check so that the CFLAGS get pulled in correctly when building. As it is, we check for the correct glproto, but don't actually use the returned CFLAGS anywhere. I can make the change later, but I don't have access to my box that's actually set up right now. Oh yeah good point. I can try to make that change too unless you beat me to it (I won't have time until tomorrow). Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Sun, 10 Jan 2010 07:32:30 +1000 Dave Airlie airl...@gmail.com wrote: I'm in the 2-3 years at a minimum, with at least one kernel with no serious regressions in Intel KMS, which we haven't gotten close to yet. I'm not even sure the Intel guys are taking stable seriously enough yet. So far I don't think there is one kernel release (even stable) that works on all Intel chipsets without backporting patches. 2.6.32 needs the changes to remove the messed up render clock hacks which should really have been reverted a lot earlier since we had a lot of regression reports. The number of users using powersave=0 to get anything approaching useable is growing etc. But you could apply that argument to the existing DRM code (not just Intel) as well; lots of things are broken or unimplemented and never get fixed. I'd say the right metric isn't whether regressions are introduced (usually due to new features) but whether the driver is better than the old userspace code. For Intel at least, I think we're already there. The quality of the kernel driver is higher and it has many more features than the userspace implementation ever did. That's just my subjective opinion, but I've done a *lot* of work on our bugs both in userspace and in the kernel, so I think it's an accurate statement. We do have ppl who run latest kernels on RHEL5 userspace and I'd rather not have that break badly, I'm guessing more than 3D will break if we remove this, since we need the DRM to allocate memory for 2D stuff, and will probably find the fallback to AGP is broken. Again Intel ppl would have to do a lot of testing on the fallback before removing anything, which is time I don't see anyone willing to spend. It doesn't have to happen anytime soon, I was just thinking that removing the old, pre-KMS code would make it easier to avoid introducing regressions since we'd have one less config (a bit one atthat) to worry about. -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Tue, 12 Jan 2010 06:12:37 +1000 Dave Airlie airl...@gmail.com wrote: On Tue, Jan 12, 2010 at 2:38 AM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Sun, 10 Jan 2010 07:32:30 +1000 Dave Airlie airl...@gmail.com wrote: I'm in the 2-3 years at a minimum, with at least one kernel with no serious regressions in Intel KMS, which we haven't gotten close to yet. I'm not even sure the Intel guys are taking stable seriously enough yet. So far I don't think there is one kernel release (even stable) that works on all Intel chipsets without backporting patches. 2.6.32 needs the changes to remove the messed up render clock hacks which should really have been reverted a lot earlier since we had a lot of regression reports. The number of users using powersave=0 to get anything approaching useable is growing etc. But you could apply that argument to the existing DRM code (not just Intel) as well; lots of things are broken or unimplemented and never get fixed. I'd say the right metric isn't whether regressions are introduced (usually due to new features) but whether the driver is better than the old userspace code. For Intel at least, I think we're already there. The quality of the kernel driver is higher and it has many more features than the userspace implementation ever did. That's just my subjective opinion, but I've done a *lot* of work on our bugs both in userspace and in the kernel, so I think it's an accurate statement. The problem is at any single point in time I'm not sure a kms kernel exists that works across all the Intel hw, which from a distro POV is a real pain in the ass, a regression gets fixed on one piece of hw just as another on a different piece gets introduced. I'd really like if Intel devs could either slow it down and do more testing before pushing to Linus, or be a lot quicker with the reverts when stuff is identified. The main thing is the render reclocking lately, thats been a nightmare and as far as I can see 2.6.32.3 still has all the issues, Yeah, it may have been better to just revert that early on, but some users really wanted the power saving features too, so it wasn't totally clear cut (btw stable has a revert patch queued up now that fixes things for several people). It doesn't have to happen anytime soon, I was just thinking that removing the old, pre-KMS code would make it easier to avoid introducing regressions since we'd have one less config (a bit one atthat) to worry about. Maybe in 3-4 years. Ouch, it just went from 2-3 to 3-4. But really the other drm drivers have to get converted anyway before we can really start killing code. -- Jesse Barnes, Intel Open Source Technology Center -- 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
[git] Support for new DRI2 protocol
DRI2 now has support for swapbuffers, OML_sync_control and events. There's a git tree at git://people.freedesktop.org/~jbarnes/mesa with support for the new requests that I'd like to push into Mesa master. Can people take a look at make sure I don't have anything horribly wrong? I've tested it against both old and new X servers (that is, servers with and w/o support for the new requests) and things seem solid, so I think it's ready to go. Building does require current dri2proto bits (all of which are in dri2proto master); I should probably spin a release of that just to make things easy. Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [PATCH] drivers/gpu/drm/i915/i915_debugfs.c: remove unnecessary casts
On Fri, 8 Jan 2010 16:24:02 -0500 H Hartley Sweeten hartl...@visionengravers.com wrote: On Friday, January 08, 2010 2:21 PM, Jesse Barnes wrote: On Fri, 8 Jan 2010 14:18:01 -0700 H Hartley Sweeten hartl...@visionengravers.com wrote: drivers/gpu/drm/i915/i915_debugfs.c: Remove unnecessary casts. The struct seq_file 'private' member is a void *, the casts are not needed. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Cc: David Airlie airl...@linux.ie This one should go to Eric Anholt e...@anholt.net, and why not just do a full drm/i915: remove unnecessary casts patch all at once? That would probably be easier for Eric. Yah, I just noticed there are a number of them in drivers/gpu/drm/*. Can Eric Anholt handle all of them or just the i915 specific ones? Just i915, the rest go through Dave. -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Fri, 8 Jan 2010 16:01:46 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Sat, 9 Jan 2010, Rafael J. Wysocki wrote: From: Rafael J. Wysocki r...@sisk.pl Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915: implement new pm ops for i915), among other things, removed the .suspend and .resume pointers from the struct drm_driver object in i915_drv.c, which broke resume without KMS on my MSI Wind U100. Fix this by reverting that part of commit cbda12d77ea59. Hmm. I get the feeling that perhaps the of the drm_driver callbacks was very muchintentional, and that the code presumably wants to be called purely through the PCI layer, and not through the drm class logic at all? Your patch seems like it would always execute the silly class suspend even though we explicitly don't want to. And a much nicer fix would seem to register the thing properly as a PCI driver even if you don't then use KMS. So it looks to me like the problem is that drm_init() will register the driver as a real PCI driver only if driver-driver_features DRIVER_MODESET and otherwise it does that very odd stealth mode manual scanning thing which doesn't register it as a proper PCI driver. So could we instead make that disable KSM _just_ disable the mode setting part, not disable the I'm a real driver part? Yeah, but that would be more invasive. In the KMS case the driver (which is registered as PCI) does a lot of the initialization that the core takes care of in the non-KMS case, and some of it happens later at ioctl time. I'm afraid of that code since it seems like whenever you change something obvious it subtly breaks an old userland. -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Fri, 8 Jan 2010 16:01:46 -0800 (PST)
Linus Torvalds torva...@linux-foundation.org wrote:
On Sat, 9 Jan 2010, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki r...@sisk.pl
Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915: implement
new pm ops for i915), among other things, removed the .suspend and
.resume pointers from the struct drm_driver object in i915_drv.c,
which broke resume without KMS on my MSI Wind U100.
Fix this by reverting that part of commit cbda12d77ea59.
Hmm. I get the feeling that perhaps the of the drm_driver callbacks
was very muchintentional, and that the code presumably wants to be
called purely through the PCI layer, and not through the drm class
logic at all?
Your patch seems like it would always execute the silly class suspend
even though we explicitly don't want to. And a much nicer fix would
seem to register the thing properly as a PCI driver even if you don't
then use KMS.
So it looks to me like the problem is that drm_init() will register
the driver as a real PCI driver only if
driver-driver_features DRIVER_MODESET
and otherwise it does that very odd stealth mode manual scanning
thing which doesn't register it as a proper PCI driver.
So could we instead make that disable KSM _just_ disable the mode
setting part, not disable the I'm a real driver part?
This is the minimal fix I think (totally untested):
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c index a0a2cad..1364c3e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -541,6 +541,11 @@ static int __init i915_init(void)
driver.driver_features = ~DRIVER_MODESET;
#endif
+ if (!(driver.driver_features DRIVER_MODESET)) {
+ driver.suspend = i915_suspend;
+ driver.resume = i915_resume;
+ }
+
return drm_init(driver);
}
--
Jesse Barnes, Intel Open Source Technology Center
--
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
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Fri, 8 Jan 2010 16:06:59 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 8 Jan 2010 16:01:46 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: On Sat, 9 Jan 2010, Rafael J. Wysocki wrote: From: Rafael J. Wysocki r...@sisk.pl Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915: implement new pm ops for i915), among other things, removed the .suspend and .resume pointers from the struct drm_driver object in i915_drv.c, which broke resume without KMS on my MSI Wind U100. Fix this by reverting that part of commit cbda12d77ea59. Hmm. I get the feeling that perhaps the of the drm_driver callbacks was very muchintentional, and that the code presumably wants to be called purely through the PCI layer, and not through the drm class logic at all? Your patch seems like it would always execute the silly class suspend even though we explicitly don't want to. And a much nicer fix would seem to register the thing properly as a PCI driver even if you don't then use KMS. So it looks to me like the problem is that drm_init() will register the driver as a real PCI driver only if driver-driver_features DRIVER_MODESET and otherwise it does that very odd stealth mode manual scanning thing which doesn't register it as a proper PCI driver. So could we instead make that disable KSM _just_ disable the mode setting part, not disable the I'm a real driver part? Yeah, but that would be more invasive. In the KMS case the driver (which is registered as PCI) does a lot of the initialization that the core takes care of in the non-KMS case, and some of it happens later at ioctl time. I'm afraid of that code since it seems like whenever you change something obvious it subtly breaks an old userland. Hm, maybe it's not as bad as I was afraid it was... we already support i915.modeset=0 even on a KMS enabled driver, which should be fairly equivalent. Rafael, if you build i915 with KMS enabled but modeset=0 do you get the right suspend/resume behavior? -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
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. -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Sat, 9 Jan 2010 02:15:41 + (GMT) Dave Airlie airl...@linux.ie wrote: From: Rafael J. Wysocki r...@sisk.pl Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915: implement new pm ops for i915), among other things, removed the .suspend and .resume pointers from the struct drm_driver object in i915_drv.c, which broke resume without KMS on my MSI Wind U100. Fix this by reverting that part of commit cbda12d77ea59. Hmm. I get the feeling that perhaps the of the drm_driver callbacks was very muchintentional, and that the code presumably wants to be called purely through the PCI layer, and not through the drm class logic at all? Your patch seems like it would always execute the silly class suspend even though we explicitly don't want to. And a much nicer fix would seem to register the thing properly as a PCI driver even if you don't then use KMS. So it looks to me like the problem is that drm_init() will register the driver as a real PCI driver only if driver-driver_features DRIVER_MODESET and otherwise it does that very odd stealth mode manual scanning thing which doesn't register it as a proper PCI driver. So could we instead make that disable KSM _just_ disable the mode setting part, not disable the I'm a real driver part? This was mainly due to pre-existing fb drivers binding to the device, and the drm drivers having to work around that, with KMS since we have fb in the drm driver its correct to bind, pre-kms its just a mess I'd rather stay away from. Linus, can we ever drop those old paths? Maybe after the new bits have been around for awhile? Users of really old userspace stacks would lose 3D support, but they'd still have 2D, so it wouldn't be a complete break. The non-KMS paths sometimes break like this anyway without us noticing (especially some of the weirder 3D paths)... Just thinking out loud, we could really kill a lot of really bad code... -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [PATCH v2] drm: Keep disabled outputs disabled after suspend / resume
On Thu, 07 Jan 2010 13:24:06 +0530 David John david...@xenontk.org wrote: On 12/31/2009 12:00 PM, David John wrote: With the current DRM code, an output that has been powered off from userspace will automatically power back on when resuming from suspend. This patch fixes this behaviour. Tested only with the Intel i915 driver on an Intel GM45 Express chipset. Signed-off-by: David John david...@xenontk.org Ping. Any update on this? Correct? Incorrect? Utter rubbish that I should be ashamed of myself? Yeah, sorry David, looks good to me. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: Intel KMS lockup with Mesa 7.7
On Tue, 22 Dec 2009 12:15:35 -0500
Nick Bowler nbow...@elliptictech.com wrote:
Please CC me as I am not subscribed to the list.
Mesa 7.7 manages to lock up the Intel KMS driver for me in some
circumstances. After running the test case (attached), the display
locks up and my kernel logs are spammed with
[drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU
hung render error detected, EIR: 0x
[drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5
(awaiting 5628 at 5621) [drm:i915_hangcheck_elapsed] *ERROR*
Hangcheck timer elapsed... GPU hung render error detected, EIR:
0x [drm:i915_do_wait_request] *ERROR* i915_do_wait_request
returns -5 (awaiting 5633 at 5621) [drm:i915_hangcheck_elapsed]
*ERROR* Hangcheck timer elapsed... GPU hung render error detected,
EIR: 0x ...
until I reset the box (other tasks continue to run on the machine).
At least all kernel versions 2.6.32 through to latest Linus git at
the time of posting are affected, but mesa 7.5.2 does not trigger the
lockup. Another interesting bit that appears in my kernel log is
mtrr: type mismatch for d000,1000 old: write-back new:
write-combining [drm] MTRR allocation failed. Graphics performance
may suffer.
The Xorg log reports my graphics card as Intel(R) G45/G43. The lockup
occurs when I try to run the following fragment shader:
uniform bool useSecondary;
uniform sampler2D tex0, tex1; /* Assigned values 0 and 1,
respectively. */ void main(void)
{
vec4 primary = texture2D(tex0, gl_TexCoord[0].st);
vec4 secondary = texture2D(tex1, gl_TexCoord[0].st);
vec3 colour= (1-primary.a)*gl_Color.rgb +
primary.a*primary.rgb;
/*
* Removing the if useSecondary here (but keeping the
* multiplication) causes the shader to work.
* The failure does not depend on the value assigned to
useSecondary. */
if (useSecondary) {
colour *= secondary.rgb;
}
gl_FragColor = vec4(colour, 1);
}
Since textures seem to be required to trigger the issue, I have
attached an archive containing the test case -- glew, glut and libpng
are required. The test case works with the software rasterizer.
Ooh, a small test case, those are always nice. Can you file a bug at
bugs.freedesktop.org, against the Intel/i965 DRI driver, with your test
case attached?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
--
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
Re: [PATCH] drm/i915: Clean up vblank data after lastclose and unload
On Tue, 5 Jan 2010 12:33:46 -0500
Kristian Høgsberg k...@bitplanet.net wrote:
Otherwise we end up waking up a freed waitqueue.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
Resend. This didn't get picked up earlier, so this time I'll try
sending to the right mailing list.
drivers/gpu/drm/drm_stub.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index ad73e14..3735478 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -515,8 +515,6 @@ void drm_put_dev(struct drm_device *dev)
}
driver = dev-driver;
- drm_vblank_cleanup(dev);
-
drm_lastclose(dev);
if (drm_core_has_MTRR(dev) drm_core_has_AGP(dev)
@@ -531,6 +529,8 @@ void drm_put_dev(struct drm_device *dev)
if (dev-driver-unload)
dev-driver-unload(dev);
+ drm_vblank_cleanup(dev);
+
if (drm_core_has_AGP(dev) dev-agp) {
kfree(dev-agp);
dev-agp = NULL;
What prevents a driver's vblank_disable hook from getting called at
cleanup time? Do we zero dev-num_crtcs or set vblank_disable_allowed?
If so, this should be safe and you can add my
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
--
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
Re: [patch for 2.6.32? 1/3] drivers/gpu/drm/i915/i915_dma.c: fix unused var
Yeah, may as well apply this one, or the printk will look funky on
GM45+ platforms.
Eric?
Jesse
On Mon, 21 Dec 2009 15:23:20 -0800
Andrew Morton a...@linux-foundation.org wrote:
This bugfix appears to have been ignored, so it missed 2.6.32.
I've tagged my 2.6.33 copy as needing a 2.6.32.x backport.
On Tue, 17 Nov 2009 14:08:52 -0800
a...@linux-foundation.org wrote:
From: Andrew Morton a...@linux-foundation.org
drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be
used uninitialized in this function
Partly this is because gcc isn't smart enough. But `ll_base' does
get used uninitialised in the DRM_DEBUG() call.
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Eric Anholt e...@anholt.net
Cc: Dave Airlie airl...@linux.ie
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/gpu/drm/i915/i915_dma.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN
drivers/gpu/drm/i915/i915_dma.c~drivers-gpu-drm-i915-i915_dmac-fix-unused-var
drivers/gpu/drm/i915/i915_dma.c ---
a/drivers/gpu/drm/i915/i915_dma.c~drivers-gpu-drm-i915-i915_dmac-fix-unused-var
+++ a/drivers/gpu/drm/i915/i915_dma.c @@ -,7 +,8 @@ static
void i915_setup_compression(struc { struct drm_i915_private
*dev_priv = dev-dev_private; struct drm_mm_node *compressed_fb,
*compressed_llb;
- unsigned long cfb_base, ll_base;
+ unsigned long cfb_base;
+ unsigned long ll_base = 0;
/* Leave 1M for line length buffer misc. */
compressed_fb = drm_mm_search_free(dev_priv-vram, size,
4096, 0); _
--
Jesse Barnes, Intel Open Source Technology Center
--
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
Re: drm: gem_object_free without struct_mutex
On Sat, 2 Jan 2010 16:46:07 +0200
Dan Carpenter erro...@gmail.com wrote:
On Wed, Dec 30, 2009 at 11:17:48PM +0100, Rafael J. Wysocki wrote:
[CC to Jesse.]
On Wednesday 30 December 2009, Hugh Dickins wrote:
I've changed BUG_ON to WARN_ON in drm_gem.c (patch at bottom) to
get this dmesg when I resume after suspend, instead of crashing.
Perhaps it's a patch that should go in, perhaps not, but obviously
the real problem lies elsewhere. Happens with 2.6.33-rc1 and
-rc2.
No surprise if I'm stupidly misconfigured to get the pin power
context error in the first place (.config on demand), but I
don't deserve to BUG!
The problem is dev_priv-mm.suspended which was set in i915_suspend().
In i915_resume()
107 i915_restore_state(dev);
The i915_restore_state() fails because i915_gem_object_bind_to_gtt()
does this:
if (dev_priv-mm.suspended)
return -EBUSY;
108
109 intel_opregion_init(dev, 1);
110
111 /* KMS EnterVT equivalent */
112 if (drm_core_check_feature(dev, DRIVER_MODESET)) {
113 mutex_lock(dev-struct_mutex);
114 dev_priv-mm.suspended = 0;
We do set the dev_priv-mm.suspended here but it's too late.
Not sure the fix though...
I think this one should be fixed by Chris's recent patchset. Should
land in Eric's tree soon.
--
Jesse Barnes, Intel Open Source Technology Center
--
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
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Wed, 16 Dec 2009 22:41:27 + Arnd Bergmann a...@arndb.de wrote: On Wednesday 16 December 2009 21:36:36 Arnd Bergmann wrote: On Wednesday 16 December 2009 21:30:05 Jesse Barnes wrote: But you're sure powersave=0 was solid? Hmm... It's hard to be sure when it sometimes takes a day before a broken version crashes. I can keep running this kernel with and without powersave=0 some more and tell you if it stays reproducible. Now it has crashed with i915.powersave=0 plus your patch as well (latest 2.6.32 git), indicating that there is something else wrong with the original 652c393a33 patch. It does very little else that should affect things. You're sure reverting the commit makes things ok? Other potential problems: - clock gating (the call to intel_init_clock_gating) - the actual mark_busy stuff itself (calls to intel_mark_busy) - intel_idle_update (but powersave=0 should prevent that) If you want to keep testing you could try removing those calls... -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Thu, 17 Dec 2009 18:52:02 +0100
Arnd Bergmann a...@arndb.de wrote:
On Thursday 17 December 2009, Jesse Barnes wrote:
It does very little else that should affect things. You're sure
reverting the commit makes things ok?
No, not sure. But I've been running the kernel before that commit
for days without ever seeing a crash. 2.6.31 (also without that
commit but otherwise pretty similar) has been stable for weeks
weeks on the same box.
Once any given kernel version crashes, which can take up to
a day while I'm waiting for the bug to show up, it will typically
crash on that same kernel again within seconds after boot,
just to annoy me and prevent me from using that kernel for
other things.
Other potential problems:
- clock gating (the call to intel_init_clock_gating)
- the actual mark_busy stuff itself (calls to intel_mark_busy)
- intel_idle_update (but powersave=0 should prevent that)
If you want to keep testing you could try removing those calls...
Ok, I'll try that. The problem is keeping me from doing any useful
upstream kernel work on my main machine, so I'm rather motivated ;-)
Another patch to try...
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 279dc96..b8ca398 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3779,125 +3779,6 @@ static void intel_gpu_idle_timer(unsigned long arg)
queue_work(dev_priv-wq, dev_priv-idle_work);
}
-void intel_increase_renderclock(struct drm_device *dev, bool schedule)
-{
- drm_i915_private_t *dev_priv = dev-dev_private;
-
- if (IS_IRONLAKE(dev))
- return;
-
- if (!dev_priv-render_reclock_avail) {
- DRM_DEBUG_DRIVER(not reclocking render clock\n);
- return;
- }
-
- /* Restore render clock frequency to original value */
- if (IS_G4X(dev) || IS_I9XX(dev))
- pci_write_config_word(dev-pdev, GCFGC, dev_priv-orig_clock);
- else if (IS_I85X(dev))
- pci_write_config_word(dev-pdev, HPLLCC, dev_priv-orig_clock);
- DRM_DEBUG_DRIVER(increasing render clock frequency\n);
-
- /* Schedule downclock */
- if (schedule)
- mod_timer(dev_priv-idle_timer, jiffies +
- msecs_to_jiffies(GPU_IDLE_TIMEOUT));
-}
-
-void intel_decrease_renderclock(struct drm_device *dev)
-{
- drm_i915_private_t *dev_priv = dev-dev_private;
-
- if (IS_IRONLAKE(dev))
- return;
-
- if (!dev_priv-render_reclock_avail) {
- DRM_DEBUG_DRIVER(not reclocking render clock\n);
- return;
- }
-
- if (IS_G4X(dev)) {
- u16 gcfgc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, GCFGC, gcfgc);
-
- /* Down to minimum... */
- gcfgc = ~GM45_GC_RENDER_CLOCK_MASK;
- gcfgc |= GM45_GC_RENDER_CLOCK_266_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
- } else if (IS_I965G(dev)) {
- u16 gcfgc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, GCFGC, gcfgc);
-
- /* Down to minimum... */
- gcfgc = ~I965_GC_RENDER_CLOCK_MASK;
- gcfgc |= I965_GC_RENDER_CLOCK_267_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
- } else if (IS_I945G(dev) || IS_I945GM(dev)) {
- u16 gcfgc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, GCFGC, gcfgc);
-
- /* Down to minimum... */
- gcfgc = ~I945_GC_RENDER_CLOCK_MASK;
- gcfgc |= I945_GC_RENDER_CLOCK_166_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
- } else if (IS_I915G(dev)) {
- u16 gcfgc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, GCFGC, gcfgc);
-
- /* Down to minimum... */
- gcfgc = ~I915_GC_RENDER_CLOCK_MASK;
- gcfgc |= I915_GC_RENDER_CLOCK_166_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
- } else if (IS_I85X(dev)) {
- u16 hpllcc;
-
- /* Adjust render clock... */
- pci_read_config_word(dev-pdev, HPLLCC, hpllcc);
-
- /* Up to maximum... */
- hpllcc = ~GC_CLOCK_CONTROL_MASK;
- hpllcc |= GC_CLOCK_133_200;
-
- pci_write_config_word(dev-pdev, HPLLCC, hpllcc);
- }
- DRM_DEBUG_DRIVER(decreasing render clock frequency\n);
-}
-
-/* Note that no increase function is needed for this - increase_renderclock()
- * will also rewrite these bits
- */
-void intel_decrease_displayclock(struct drm_device *dev)
-{
- if (IS_IRONLAKE(dev))
- return;
-
- if (IS_I945G(dev) || IS_I945GM(dev
Re: 2.6.32.1 i915 KMS rmmod failure
On Wed, 16 Dec 2009 20:08:16 +0100
Krzysztof Halasa k...@pm.waw.pl wrote:
Hi,
The following sequence causes the machine to hang hard:
modprobe drm debug=65535
modprobe i915 modeset=1
rmmod i915
Linux 2.6.32.1 x86-64, i915 (the machine is a slimline MSI Hetis 915
barebone), 2 GB RAM etc. Kernel messages captured with a serial
console. Only analog VGA output connected (no EDID, using a pro 5 *
BNC cable to connect to an old analog monitor). There is
(unconnected) digital DVI and a TV encoder. Other details available
on request.
The IRQ happens in intel_pipe_set_base()
DRM_DEBUG(Writing base %08lX %08lX %d %d\n, Start, Offset,
x, y); I915_WRITE(dspstride, crtc-fb-pitch);
if (IS_I965G(dev)) {
...
} else {
I915_WRITE(dspbase, Start + Offset);
I915_READ(dspbase);
IRQ seems to be triggered at this point
}
Any ideas?
Seems like we should be disabling everything at unload time rather than
trying to set a new mode... If the dspbase we program isn't mapped
anymore we'd definitely get into trouble.
--
Jesse Barnes, Intel Open Source Technology Center
--
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
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Wed, 16 Dec 2009 21:20:34 + Arnd Bergmann a...@arndb.de wrote: On Wednesday 16 December 2009 20:18:23 Jesse Barnes wrote: On Wed, 16 Dec 2009 14:53:11 +0100 Arnd Bergmann a...@arndb.de wrote: It's working fine so far, no more crashes, but I supposed this effectively disables the power saving on my card again, right? The patch just disables one (probably ineffective) power saving feature. So if things are working well for you with it I'll queue up a revert patch. I'm working on a better version of dynamic clock control anyway. It just crashed again after a few hours of uptime with some unrelated reboots in-between, with your patch applied. The symptom was slightly different, now the whole screen was filled with random patterns, not just parts of the screen. Aside from that, it was just the same complete lockup as without the patch. Possibly less frequent, but that's hard to tell after a single sample. But you're sure powersave=0 was solid? Hmm... -- Jesse Barnes, Intel Open Source Technology Center -- 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
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Mon, 14 Dec 2009 07:54:05 +1000 Dave Airlie airl...@redhat.com wrote: On Sun, 2009-12-13 at 21:31 +, Arnd Bergmann wrote: On Sunday 13 December 2009 20:00:18 Daniel Vetter wrote: On Sun, Dec 13, 2009 at 12:30:25PM +, Arnd Bergmann wrote: And now it's obvious that my computer hates me. 12 hours of uptime, one reboot to check the old other version is broken, it crashes. I reboot into the good version, send out the above email and the next minute it crashes again. c05422d52ee6b is not the culprit. Sorry Daniel for blaming your patch. No problem. Looks like your hunting a pretty ugly Heisenbug. There's quite a interesting blog post by Paul McKenney, esp. the solution to Quick Quiz 1 might be usefull in your case: http://paulmck.livejournal.com/14639.html Thanks! In fact I've actually read that post on the kernel planet and decided to do basically a linear search through the i915 patches merged into 2.6.32. The current result is 67cf781bea5 drm/i915: Make the downclocking debug code be under DRM_DEBUG not DRM_ERROR. is known bad, while 043029655 drm/i915: Support IGD EOS is probably good, pointing to Jesses 652c393a33 drm/i915: add dynamic clock frequency control as the next best guess. Unfortunately, that is a rather large change that is not easy to revert on current kernels. That seems the most likely, perhaps jbarnes can comment. You can disable most of that code by loading i915 with 'powersave=0'. If that patch really is at fault the powersave=0 should work around the issue as well. It's been implicated in another issue (some display flicker and underruns) so I'm pretty sure there's something wrong with it in some configurations at least... -- Jesse Barnes, Intel Open Source Technology Center -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Mon, 14 Dec 2009 20:38:09 +
Arnd Bergmann a...@arndb.de wrote:
On Monday 14 December 2009 18:20:15 Jesse Barnes wrote:
You can disable most of that code by loading i915 with
'powersave=0'. If that patch really is at fault the powersave=0
should work around the issue as well.
Ok, I'll try that and let you know. Running the kernel before your
patch has not crashed yet after two days of uptime. Now running
with your patch but nothing else. When that crashes, I'll try
the latest mainline with powersave=0.
Ok great.
It's been implicated in another issue (some display flicker and
underruns) so I'm pretty sure there's something wrong with it in
some configurations at least...
I haven't seen that yet. FWIW, the device in question is
[snip 4 series pci info]
Let me know if you have a patch you want me to test.
This patch removes the suspect portion of the dynamic clock control
code. Hopefully it'll be as stable as powersave=0 in your config
(assuming powersave=0 works :).
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 279dc96..b8730de 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3825,8 +3825,6 @@ void intel_decrease_renderclock(struct drm_device *dev)
/* Down to minimum... */
gcfgc = ~GM45_GC_RENDER_CLOCK_MASK;
gcfgc |= GM45_GC_RENDER_CLOCK_266_MHZ;
-
- pci_write_config_word(dev-pdev, GCFGC, gcfgc);
} else if (IS_I965G(dev)) {
u16 gcfgc;
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
On Thu, 10 Dec 2009 10:42:46 -0800 (PST) Linus Torvalds torva...@linux-foundation.org wrote: I _think_ that last one was meant as a joke. But it's damn hard to tell, because the ones that are apparently sincere are equally crazy. People just seem to make up total crap to make excuses for something that everybody knows is wrong. Heh. I was only half-kidding. My point was that Fedora (for the purposes of graphics at least) is more like an individual developer's (or small group's) work tree that just happens to be available publicly. If you think of it that way, it kind of makes sense that some changes it includes aren't pushed upstream right away. But I fully admit it's a bogus excuse and a fairly cheap shot at Fedora. :) -- Jesse Barnes, Intel Open Source Technology Center -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [libdrm tests ebuild error] modetest needs update?
On Fri, 04 Dec 2009 17:22:22 +0100 Tobias Jakobi liquid.a...@gmx.net wrote: Hi there, with a fresh git master from the libdrm repo compilation fails: make[3]: Entering directory `/var/tmp/portage/x11-libs/libdrm-/work/libdrm-/tests/modetest' i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include/drm -I../../intel/ -I../.. -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -O2 -march=pentium-m -fomit-frame-pointer -pipe -MT modetest.o -MD -MP -MF .deps/modetest.Tpo -c -o modetest.o modetest.c modetest.c: In function ‘dump_framebuffers’: modetest.c:259: warning: too few arguments for format modetest.c: In function ‘set_mode’: modetest.c:621: error: ‘drmEventContext’ has no member named ‘pageflip_handler’ modetest.c: In function ‘main’: modetest.c:700: warning: format ‘%64s’ expects type ‘char *’, but argument 4 has type ‘char (*)[64]’ modetest.c:704: warning: format ‘%64s’ expects type ‘char *’, but argument 5 has type ‘char (*)[64]’ Looking at drmEventContext in xf86drm.h the member is called page_flip_handler, and NOT pageflip_handler. Can someone push a fix? Yep, fix pushed. -- Jesse Barnes, Intel Open Source Technology Center -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/i915: add GETPARAM request for page flipping
On Tue, 01 Dec 2009 09:18:51 -0800 Eric Anholt e...@anholt.net wrote: On Thu, 19 Nov 2009 10:49:07 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Wed, 18 Nov 2009 04:31:47 + Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org OK, I've applied this series in what I'm guessing was the desired order: 1) pageflipping support 2) core fixup 3) getparam to say it's ready Also, something seems wonky with your patches. The git am gives me: anh...@gaiman:anholt/src/linux-2.6% git log commit b0f57d0ff95c957b278d7a82d9ebdea395652cfa Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Nov 19 10:49:07 2009 -0800 drm/i915: add GETPARAM request for page flipping From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Wed, 18 Nov 2009 04:31:47 + Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Eric Anholt e...@anholt.net Are you not using git send-email? No, I used format-patch and then sent them by hand. git am should still work though, unless I got the -- wrong somehow... -- Jesse Barnes, Intel Open Source Technology Center -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Fix sync to vblank when VGA output is turned off
On Tue, 01 Dec 2009 10:28:17 -0800 Eric Anholt e...@anholt.net wrote: On Mon, 09 Nov 2009 12:51:22 +0800, Li Peng peng...@linux.intel.com wrote: In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by: Li Peng peng...@intel.com Applied. Thanks! Kristian, I think we'll need to tie into this for outstanding page flips at DPMS off time. If we DPMS off while one is pending, I think we should complete it immediately and send the event. I'm not sure what to do about the case where we received the flip pending interrupt but haven't received the vblank event though... Presumably in that case the base register will have been updated, but if not I'm not sure what will happen... -- Jesse Barnes, Intel Open Source Technology Center -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/4] drm/modes: Limit fallback modes to 60Hz
On Mon, 23 Nov 2009 14:23:04 -0500
Adam Jackson a...@redhat.com wrote:
See also: http://bugzilla.redhat.com/514600
Signed-off-by: Adam Jackson a...@redhat.com
---
drivers/gpu/drm/drm_edid.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cea665d..dd95edf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1290,6 +1290,8 @@ int drm_add_modes_noedid(struct drm_connector
*connector, ptr-vdisplay vdisplay)
continue;
}
+ if (drm_mode_vrefresh(ptr) 61)
+ continue;
mode = drm_mode_duplicate(dev, ptr);
if (mode) {
drm_mode_probed_add(connector, mode);
Series looks nice to me, thanks Adam.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Add intel implementation of the pageflip ioctl
Dave, here's an updated version that fixes the checkpatch warnings, removes a
stray line (the forced alignment hack) and fixes pre-965 support. I have
some related followup patches, but I think this one is ready.
Thanks,
Jesse
--
From 2bec6039e7e6180a981971665be712f5a5b9b0e0 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Kristian=20H=C3=B8gsberg?= k...@bitplanet.net
Date: Tue, 17 Nov 2009 12:43:56 -0500
Subject: [PATCH 1/4] Add intel implementation of the pageflip ioctl
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Acked-by: Jakob Bornecrantz ja...@vmware.com
Acked-by: Thomas Hellström tho...@shipmail.org
Review-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Jesse Orange Smoothie Barnes jbar...@virtuousgeek.org
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
drivers/gpu/drm/i915/i915_drv.h | 12 ++
drivers/gpu/drm/i915/i915_gem.c | 64 +-
drivers/gpu/drm/i915/i915_irq.c | 10 ++
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_display.c | 237 +-
drivers/gpu/drm/i915/intel_drv.h |3 +
6 files changed, 294 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 835625b..75acb5d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -536,6 +536,10 @@ typedef struct drm_i915_private {
/* indicate whether the LVDS_BORDER should be enabled or not */
unsigned int lvds_border_bits;
+ struct drm_crtc *plane_to_crtc_mapping[2];
+ struct drm_crtc *pipe_to_crtc_mapping[2];
+ wait_queue_head_t pending_flip_queue;
+
/* Reclocking support */
bool render_reclock_avail;
bool lvds_downclock_avail;
@@ -635,6 +639,13 @@ struct drm_i915_gem_object {
* Advice: are the backing pages purgeable?
*/
int madv;
+
+ /**
+* Number of crtcs where this object is currently the fb, but
+* will be page flipped away on the next vblank. When it
+* reaches 0, dev_priv-pending_flip_queue will be woken up.
+*/
+ atomic_t pending_flip;
};
/**
@@ -826,6 +837,7 @@ void i915_gem_free_all_phys_object(struct drm_device *dev);
int i915_gem_object_get_pages(struct drm_gem_object *obj);
void i915_gem_object_put_pages(struct drm_gem_object *obj);
void i915_gem_release(struct drm_device * dev, struct drm_file *file_priv);
+void i915_gem_object_flush_write_domain(struct drm_gem_object *obj);
void i915_gem_shrinker_init(void);
void i915_gem_shrinker_exit(void);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2065b8f..55ed06f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2771,6 +2771,22 @@ i915_gem_object_flush_cpu_write_domain(struct
drm_gem_object *obj)
old_write_domain);
}
+void
+i915_gem_object_flush_write_domain(struct drm_gem_object *obj)
+{
+ switch (obj-write_domain) {
+ case I915_GEM_DOMAIN_GTT:
+ i915_gem_object_flush_gtt_write_domain(obj);
+ break;
+ case I915_GEM_DOMAIN_CPU:
+ i915_gem_object_flush_cpu_write_domain(obj);
+ break;
+ default:
+ i915_gem_object_flush_gpu_write_domain(obj);
+ break;
+ }
+}
+
/**
* Moves a single object to the GTT read, and possibly write domain.
*
@@ -3536,6 +3552,41 @@ i915_gem_check_execbuffer (struct
drm_i915_gem_execbuffer *exec,
return 0;
}
+static int
+i915_gem_wait_for_pending_flip(struct drm_device *dev,
+ struct drm_gem_object **object_list,
+ int count)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ struct drm_i915_gem_object *obj_priv;
+ DEFINE_WAIT(wait);
+ int i, ret = 0;
+
+ for (;;) {
+ prepare_to_wait(dev_priv-pending_flip_queue,
+ wait, TASK_INTERRUPTIBLE);
+ for (i = 0; i count; i++) {
+ obj_priv = object_list[i]-driver_private;
+ if (atomic_read(obj_priv-pending_flip) 0)
+ break;
+ }
+ if (i == count)
+ break;
+
+ if (!signal_pending(current)) {
+ mutex_unlock(dev-struct_mutex);
+ schedule();
+ mutex_lock(dev-struct_mutex);
+ continue;
+ }
+ ret = -ERESTARTSYS;
+ break;
+ }
+ finish_wait(dev_priv-pending_flip_queue, wait);
+
+ return ret;
+}
+
int
i915_gem_execbuffer(struct drm_device *dev, void *data,
struct drm_file *file_priv)
@@ -3551,7 +3602,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
[PATCH 1/2] drm/i915: add GETPARAM request for page flipping
From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Wed, 18 Nov 2009 04:31:47 +
Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping
Add a GETPARAM request for checking if page flipping is supported.
Useful for the 2D driver to enable the flipping path.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
include/drm/i915_drm.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 093146b..419b399 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -810,6 +810,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_OVERLAY:
value = dev_priv-overlay ? 1 : 0;
break;
+ case I915_PARAM_HAS_PAGEFLIPPING:
+ value = 1;
+ break;
default:
DRM_DEBUG_DRIVER(Unknown parameter %d\n,
param-param);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index c900499..1b4f3a5 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -271,6 +271,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_GEM 5
#define I915_PARAM_NUM_FENCES_AVAIL 6
#define I915_PARAM_HAS_OVERLAY 7
+#define I915_PARAM_HAS_PAGEFLIPPING 8
typedef struct drm_i915_getparam {
int param;
--
1.6.1.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm: use page flip event to signal flip completion
From fa621056b43d24ca97b61863c8566ac12696ce25 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Thu, 19 Nov 2009 10:25:46 -0800
Subject: [PATCH 2/2] drm: use page flip event to signal flip completion
We don't actually know which frame number the flip will complete on, so
userspace needs a specific flip notification to tell it when the last flip
completed.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_crtc.c |2 +-
include/drm/drm.h |1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ac2fa19..3bc870d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2527,7 +2527,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto out;
}
- e-event.base.type = DRM_EVENT_VBLANK;
+ e-event.base.type = DRM_EVENT_FLIP_COMPLETE;
e-event.base.length = sizeof e-event;
e-event.user_data = page_flip-user_data;
e-base.event = e-event.base;
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 3919a4f..309d0a5 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -718,6 +718,7 @@ struct drm_event {
};
#define DRM_EVENT_VBLANK 0x01
+#define DRM_EVENT_FLIP_COMPLETE 0x02
struct drm_event_vblank {
struct drm_event base;
--
1.6.1.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: let pin routine figure out appropriate alignment
From 8adb52b4529e777d4df0356bc2c8ef5453c2322e Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@jbarnes-desktop.localdomain
Date: Wed, 18 Nov 2009 09:56:25 -0800
Subject: [PATCH] drm/i915: let pin routine figure out appropriate alignment
When this code got moved out of intel_pipe_set_base, it grew a forced
alignment of 256k, which wasn't always correct. Remove that and let the
pin routine figure out the correct alignment for the object (it should
do this in just about every case).
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 20 +---
1 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c7d5611..b4c6b40 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1193,27 +1193,9 @@ static int
intel_pin_and_fence_fb_obj(struct drm_device *dev, struct drm_gem_object *obj)
{
struct drm_i915_gem_object *obj_priv = obj-driver_private;
- u32 alignment;
int ret;
- switch (obj_priv-tiling_mode) {
- case I915_TILING_NONE:
- alignment = 64 * 1024;
- break;
- case I915_TILING_X:
- /* pin() will align the object as required by fence */
- alignment = 0;
- break;
- case I915_TILING_Y:
- /* FIXME: Is this true? */
- DRM_ERROR(Y tiled not allowed for scan out buffers\n);
- return -EINVAL;
- default:
- BUG();
- }
-
- alignment = 256 * 1024;
- ret = i915_gem_object_pin(obj, alignment);
+ ret = i915_gem_object_pin(obj, 0);
if (ret != 0)
return ret;
--
1.6.1.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: let pin routine figure out appropriate alignment
On Wed, 18 Nov 2009 18:33:30 + Chris Wilson ch...@chris-wilson.co.uk wrote: Excerpts from Jesse Barnes's message of Wed Nov 18 17:58:42 + 2009: From 8adb52b4529e777d4df0356bc2c8ef5453c2322e Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@jbarnes-desktop.localdomain Date: Wed, 18 Nov 2009 09:56:25 -0800 Subject: [PATCH] drm/i915: let pin routine figure out appropriate alignment When this code got moved out of intel_pipe_set_base, it grew a forced alignment of 256k, which wasn't always correct. Remove that and let the pin routine figure out the correct alignment for the object (it should do this in just about every case). I thought the only reason why pin() took an alignment parameter was so that we could specify a minimum alignment of 64k for untiled scan out buffers. Are we confident that this is not the case? Well there are a few other places that want a specific alignment (though mostly 4k so redundant). But yeah we do need to preserve the 64k alignment for non-tiled scanout. I'll fix up the patch. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] DRI2 synchronization and swap bits
. Right, if we have the averaged difference we could just calculate it. Here is another proposal that i would love to see in Linux: A good method to find the accurate time of the last vblank immediately, irrespective of possible delays in irq dispatching, is to use the current scanout position of the crtc as a high resolution clock that counts time since start of the vertical blank interval. Afaik basically all GPU's have a register that allows to read out the currently scanned out scanline. If the exact duration of a video refresh interval 'refreshduration' is known by measurement, the current 'scanline' is known by a register read, the total height of the display vtotal is known, and one has a timestamp of current system time tsystem from do_gettimeofday(), one can conceptually implement this pseudo-code: scanline = dev-driver-getscanline(dev, crtc); tsystem = do_gettimeofday(...); tvblank = tsystem - refreshduration * (scanline / vtotal); (One has to measure scanline relative to the first line inside the vblank area though, and the math might be a bit more complex, due to the lack of floating point arithmetic in the kernel?). This would allow to quickly reinitialize the vblank timestamp in drm_update_vblank_count() and to provide vblank timestamps from inside drm_handle_vblank() which are robust against interrupt dispatch latency. It would require a new callback function into the GPU specific driver, e.g., dev-driver-getscanline(dev, crtc). One could have a simple do_gettimeofday(tvblank) as fallback for drivers that don't implement the new callback. Maybe one could even implement a dev-driver-getvblanktime(dev, crtc); callback that executes the above lines inside one function and optionally allows use of more clever GPU specific strategies like GPU internal clocks and snapshot registers? Seems worth prototyping at least. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Tue, 17 Nov 2009 18:53:22 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: On Tue, Nov 17, 2009 at 18:07, Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 9 Nov 2009 17:46:44 +0100 Stephane Marchesin marche...@icps.u-strasbg.fr wrote: And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. That's another issue, but 3 months is too quick to be stable (and I think no one but intel here wants to do 3 months cycles anyway). Btw the kernel releases every 3 months. That's why libdrm should be following the kernel releases and go along with it: the kernel gets very wide testing and we'd hook on to that good testing crowd. Right now libdrm releases are virtually invisible to the OSS people. There's no serious development, no RCs, etc. Since wee can't even pretend to do proper releases, I'd say hook on to the kernel's as those work. I don't see big advantages to packaging it with the kernel, mainly disadvantages. I don't think it'll get wider testing if it's in the kernel, and I don't think compatibility will be easier to maintain. FWIW, you gave me the opposite argument when you decided that DRM development should happen in the kernel. Back then you used to say that we'd get more testers that way. Which one should I believe? Testers for kernel code, yes. Testers for libdrm code, no. When I install a new kernel I don't typically install new headers and all the other junk that comes with the new kernel, I just install the vmlinuz and make a new initrd if necessary. I don't think I'm alone. But even if we concede that libdrm would get more testers if included in the kernel, there are still other issues to deal with. There's a big downside too, since it makes packaging much harder. Distros typically stick with one kernel for a relatively long time, but if they want to pick up a libdrm fix unrelated to a new DRM interface (like the one Remi pointed out) they'll have to grab a recent kernel, extract libdrm, and make sure it works with their current kernel (which may involve some extra work if new DRM interfaces have gone in too). Yes, but the positive side is that distros using a standard/old (about a year) kernel don't need to crawl the old libdrm repo and find the right version (in your case they have to do this ° backport stuff) ... I think that plus the fact that it makes development and merging simpler is just a reason to do it. Presumably they'd want the last released version... Anyway I'm just dubious about moving most userland code into the kernel; udev, klibc, etc. I think it makes more things harder than it does easier. But like Kristian said, it's really a separate discussion from making a more standalone libdrm repo. Nothing stops you (or anyone else) from taking that new repo and proposing it for inclusion in the kernel. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/2] drm/i915: add GETPARAM request for page flipping
From c27e509840589cf4c175f615ec6e3d48e05944c5 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@jbarnes-desktop.localdomain
Date: Wed, 18 Nov 2009 04:31:47 +
Subject: [PATCH] drm/i915: add GETPARAM request for page flipping
Add a GETPARAM request for checking if page flipping is supported.
Useful for the 2D driver to enable the flipping path.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
include/drm/i915_drm.h |1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 093146b..419b399 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -810,6 +810,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_OVERLAY:
value = dev_priv-overlay ? 1 : 0;
break;
+ case I915_PARAM_HAS_PAGEFLIPPING:
+ value = 1;
+ break;
default:
DRM_DEBUG_DRIVER(Unknown parameter %d\n,
param-param);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index c900499..1b4f3a5 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -271,6 +271,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_GEM 5
#define I915_PARAM_NUM_FENCES_AVAIL 6
#define I915_PARAM_HAS_OVERLAY 7
+#define I915_PARAM_HAS_PAGEFLIPPING 8
typedef struct drm_i915_getparam {
int param;
--
1.6.1.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] GLX_INTEL_swap_event
Kristian, Chris and I met with some of the Clutter/Mutter developers last week and came up with a new GLX extension to help GLX integrate more naturally into glib style event loops: http://people.freedesktop.org/~jbarnes/swapbufferevent.txt The basic idea is that glXSwapBuffers should be asynchronous (i.e. return immediately and swap at some point in the future based on swap interval settings, busy buffers, etc.). In order to really take advantage of this fact though, it helps if clients can perform other work that won't cause them to block (e.g. rendering to one of the busy buffers from a previous swap). Since knowledge of the busy buffers or which operations might require them may not be present at all levels in client code, having a notification arrive when swaps complete can help. Clients can process non-GL related code until the event arrives, then start preparing their next frame. Note that this in no way prevents clients from queuing multiple swaps (e.g. with triple buffering or N-buffering), it just notifies them when swaps complete. The latest implementation bits for this extension are in my personal repos: glxproto, dri2proto, xserver and mesa. Is this something people feel is generally useful? Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] GLX_INTEL_swap_event
On Mon, 16 Nov 2009 11:51:31 -0800 Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Barnes wrote: Kristian, Chris and I met with some of the Clutter/Mutter developers last week and came up with a new GLX extension to help GLX integrate more naturally into glib style event loops: http://people.freedesktop.org/~jbarnes/swapbufferevent.txt I think I'd replace blit with copy in the spec. Yeah, probably better. What is the utility to the application of knowing GLX_FLIP_COMPLETE vs GLX_EXCHANGE_COMPLETE? It was easy to provide... I had vague thoughts that the client lib could check the return value against its expectations, but admittedly I don't have a use case for exchange vs. flip (basically just indicates whether the swap was a full screen or windowed flip). The GLX_BUFFER_SWAP_COMPLETE_INTEL event should just return the enum values instead of 1, 2, or 3. This is what is done for the GLX_BUFFER_CLOBBER_MASK_SGIX event, for example. Oh sure. I think the spec doesn't match the implementation in this sense. I'll fix the spec. :) All X events are 32 bytes, but GLX_BUFFER_SWAP_COMPLETE_INTEL is 34 bytes. Perhaps the SBC could be only 4-bytes? Having more than 2**32 buffers swaps seems unlikely. :) Arg, miscounted. :) That would make it fail to match the OML stuff, but is probably ok... Minor nit... Since many specs have issues lists that are longer than the spec, we've started putting the issues list at the end. Look at a recent spec for an example: http://www.opengl.org/registry/specs/ARB/glx_create_context.txt Ok, I'll move it to the end. Thanks for checking it out. What's the ARB process for this? Once we're shipping an implementation should it be hosted at the opengl GLX extension registry? Or do we need some ARB approval of the event code we're using? -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] GLX_INTEL_swap_event
On Mon, 16 Nov 2009 13:25:01 -0800 Ian Romanick i...@freedesktop.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Barnes wrote: On Mon, 16 Nov 2009 11:51:31 -0800 Ian Romanick i...@freedesktop.org wrote: All X events are 32 bytes, but GLX_BUFFER_SWAP_COMPLETE_INTEL is 34 bytes. Perhaps the SBC could be only 4-bytes? Having more than 2**32 buffers swaps seems unlikely. :) Arg, miscounted. :) That would make it fail to match the OML stuff, but is probably ok... Only in the protocol. The structure returned to clients can still use uint64_t. Right? Yeah, true. Thanks for checking it out. What's the ARB process for this? Once we're shipping an implementation should it be hosted at the opengl GLX extension registry? Or do we need some ARB approval of the event code we're using? To get the spec posted in the registry, I just need to put it in the Khronos SVN repo and as Jon to mirror it to the website. The enum values are allocated, in blocks, to implementers. It doesn't look like Mesa or Intel have any GLX enums reserved. I'll have to ask for a block. It will *probably* be 0x8180 through 0x818F. It looks like we also need an event code. This will probably be 17. I'm not sure what the process is for the event mask bit, so I'll ask. Great, thanks. -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: when queuing an event with NEXTONMISS, return queued sequence to userspace
On Tue, 10 Nov 2009 08:21:25 +
Jesse Barnes jbar...@virtuousgeek.org wrote:
If we queue a vblank event but miss it, we should return the actual
sequence number we queued to userspace, so its event handling function
will know which event to look for.
Acked-by: Kristian Høgsberg k...@bitplanet.net
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 72754ac..6b3ce6d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -585,6 +585,7 @@ static int drm_queue_vblank_event(struct
drm_device *dev, int pipe, if ((vblwait-request.type
_DRM_VBLANK_NEXTONMISS) (seq - vblwait-request.sequence) = (1
23)) { vblwait-request.sequence = seq + 1;
+ vblwait-reply.sequence = vblwait-request.sequence;
}
DRM_DEBUG(event on vblank count %d, current %d, crtc %d\n,
Ignore this one I sent out the wrong patch.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: when queuing an event with NEXTONMISS, return queued sequence to userspace
If we queue a vblank event but miss it, we should return the actual
sequence number we queued to userspace, so its event handling function
will know which event to look for.
Acked-by: Kristian Høgsberg k...@bitplanet.net
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 72754ac..6b3ce6d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -585,6 +585,7 @@ static int drm_queue_vblank_event(struct drm_device *dev,
int pipe,
if ((vblwait-request.type _DRM_VBLANK_NEXTONMISS)
(seq - vblwait-request.sequence) = (1 23)) {
vblwait-request.sequence = seq + 1;
+ vblwait-reply.sequence = vblwait-request.sequence;
}
DRM_DEBUG(event on vblank count %d, current %d, crtc %d\n,
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix sync to vblank when VGA output is turned off
On Mon, 09 Nov 2009 12:51:22 +0800 Li Peng peng...@linux.intel.com wrote: In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by: Li Peng peng...@intel.com Looks like a good patch, thanks for fixing this up. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org Thanks, Jesse -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: work around EDIDs with bad htotal/vtotal values
On Thu, 5 Nov 2009 10:12:54 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: We did this on the userspace side, but we need a similar fix for the kernel. Fixes LP #460664. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Dave, this should be cc'd to stable as well. Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] DRI2 synchronization and swap bits
On Sun, 1 Nov 2009 21:46:45 +0100
Mario Kleiner mario.klei...@tuebingen.mpg.de wrote:
I read this RFC and i'm very excited about the prospect of having
well working support for the OML_sync_control extension in DRI2 on
Linux/X11. I was hoping for this to happen since years, so a big
thank you in advance! This is why i hope to provide some input from
the perspective of future power-users of functions like
glXGetSyncValuesOML(), glXSwapBuffersMscOML(), glXWaitForSbcOML. I'm
the co-developer of a popular free-software toolkit (Psychtoolbox)
that is used mostly in the neuroscience / cognitive science
community by scientist to find out how the different senses (visual,
auditory, haptic, ...) work and how they work together. Our
requirements to graphics are often much more demanding than what a
videogame, typical vr-environment or a mediaplayer has.
Thanks a lot for taking time to go through this stuff, it's exactly the
kind of feedback I was hoping for.
Our users often have very strict requirements for scheduling frame-
accurate and tear-free visual stimulus display, synchronizing
bufferswaps across display-heads, and low-latency returns from swap-
completion. Often they need swap-completion timestamps which are
available with the shortest possible delay after a successfull swap
and accurately tied to the vblank at which scanout of a swapped
frame started. The need for timestamps with sub-millisecond accuracy
is not uncommon. Therefore, well working OML_sync_control support
would be basically a dream come true and a very compelling feature
for Linux as a platform for cognitive science.
Doing the wakeups within a millisecond should definitely be possible,
I don't expect the context switch between display server and client
would be *that* high of a cost (but as I said I'll benchmark).
2. On the CompositePage in the DRM Wiki, there is this comment:
...It seems that composited apps should never need to know about
real world screen vblank issues, ... When dealing with a
redirected window it seems it would be acceptable to come up with an
entirely fake number for all existing extensions that care about
vblanks..
I don't like this idea about entirely fake numbers and like to vote
for a solution that is as close as possible to the non-redirected
case. Most of our applications run in non-redirected, full-screen,
undecorated, page-flipped windows, ie., without a compositor being
involved. I can think of a couple future usage cases though where
reasonably well working redirected/composited windows would be very
useful for us, but only if we get meaningful timestamps and vblank
counts that are tied to the actual display onset.
The raw numbers will always be exposed to the compositor and probably
to applications via an opt-out mechanism (to be defined still, we don't
even have the extra compositor protocol defined).
3. The Wiki also mentions The direct rendered cases outlined in the
implementation notes above are complete, but there's a bug in the
async glXSwapBuffers that sometimes causes clients to hang after
swapping rather than continue. Looking through the code of http://
cgit.freedesktop.org/~jbarnes/xf86-video-intel/tree/src/i830_dri.c?
id=a0e2e624c47516273fa3d260b86d8c293e2519e4 i can see that in
I830DRI2SetupSwap() and I830DRI2SetupWaitMSC(), in the if (divisor
== 0) { ...} path, the functions return after DRM_VBLANK_EVENT
submission without assigning *event_frame = vbl.reply.sequence;
This looks problematic to me, as the xserver is later submitting
event_frame in the call to DRI2AddFrameEvent() inside DRI2SwapBuffers
() as a cookie to find the right events for clients to wait on?
Could this be a reason for clients hanging after swap? I found a few
other spots where i other misunderstood something or there are small
bugs. What is the appropriate way to report these?
This list is fine, thanks for checking it out. I'll fix that up.
4. According to spec, the different OML_sync_control functions do
return a UST timestamp which is supposed to reflect the exact time
of when the MSC last incremented, i.e., at the start of scanout of a
new video frame. SBC and MSC are supposed to increment atomically/
simultaneously at swap completion, so the UST in the (UST,SBC,MSC)
triplet is supposed to mark the time of transition of either MSC or
MSC and SBC at swap completion. This makes a lot of sense to me, it
is exactly the type of timestamp that our toolkit critically depends
on.
Ideally the UST timestamp should be corrected to reflect start of
scanout, but a UST that is consistently taken at vblank interrupt
time would do as well. In the current implementation this is *not*
the semantic we'd get for UST timestamps.
The I830DRI2GetMSC() call uses a call to drmWaitVBlank() and its
returned vbl.reply.tval_sec and vbl.reply.tval_usec values for
computing UST.
