Re: [Intel-gfx] [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver
At Mon, 21 Nov 2011 09:58:09 +0800, Wu Fengguang wrote: On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote: On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang fengguang...@intel.com wrote: However when in X, -mode_set won't be called at all. Only -get_modes and -detect are called... The desktop software will call mode_set when it configures the monitor. Otherwise, it's not being used (and so shouldn't have audio routed to it by default). Keith, I experimented playing HDMI audio in X, and during the time unplug and plug the monitor. The HDMI audio/graphics all continue to work when plugged in the monitor again. Here is the dmesg showed for the plug event, no -mode_set is called at all... Which desktop system are you using? At hotplug/unplugging, the kernel drm issues a udev event, X Intel driver receives it and updates Xrandr. Then it's supposed that a daemon like gnome-settings-daemon receives Xrandr notification and changes the modes appropriately. Without such a background task, there will be no mode change. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/13] drm/i915: fall through pwrite_gtt_slow to the shmem slow path
On Sun, 20 Nov 2011 19:09:18 -0800, Ben Widawsky b...@bwidawsk.net wrote: On Sun, 6 Nov 2011 20:13:48 +0100 Daniel Vetter daniel.vet...@ffwll.ch wrote: The gtt_pwrite slowpath grabs the userspace memory with get_user_pages. This will not work for non-page backed memory, like a gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit -EFAULT in the gtt paths. Now the shmem paths have exactly the same problem, but this way we only need to rearrange the code in one write path. v2: v1 accidentaly falls back to shmem pwrite for phys objects. Fixed. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch It would be nice if there was some way to notify users that pwriting a gtt mmapped address can be really damn slow. That's also the one behavior change this patch introduces. It's possible that some SW was expecting to get a, fast path and would deal with the -EFAULT if it didn't get it. The behaviour change is intentional. Before this patch we would deadlock... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver
On Mon, Nov 21, 2011 at 04:47:38PM +0800, Takashi Iwai wrote: At Mon, 21 Nov 2011 09:58:09 +0800, Wu Fengguang wrote: On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote: On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang fengguang...@intel.com wrote: However when in X, -mode_set won't be called at all. Only -get_modes and -detect are called... The desktop software will call mode_set when it configures the monitor. Otherwise, it's not being used (and so shouldn't have audio routed to it by default). Keith, I experimented playing HDMI audio in X, and during the time unplug and plug the monitor. The HDMI audio/graphics all continue to work when plugged in the monitor again. Here is the dmesg showed for the plug event, no -mode_set is called at all... Which desktop system are you using? At hotplug/unplugging, the kernel drm issues a udev event, X Intel driver receives it and updates Xrandr. Then it's supposed that a daemon like gnome-settings-daemon receives Xrandr notification and changes the modes appropriately. Without such a background task, there will be no mode change. Ah I got it. I'm running debian+fluxbox w/o those fancy features... Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] WARNING: at drivers/gpu/drm/i915/intel_display.c:792
Hi My Xorg server on rawhide machine is giving me sudden X lockups with 3.1 kernel. There might be couple issue related together as rawhide is now using some experimental Xorg server - but the message from kernel is a bit scary - so reposting to lkml as well. xorg-x11-server-Xorg-1.11.99.1-6.2009.fc17.x86_64 git intel driver: 3b9479dc39d32fd97f80c1e5e0fac67d36ee5e40 drm version (a bit older): 8d055890d90c3d92647e3d8b98d32630ef87c2c8 (since current Fedora rawhide intel driver is so much broken it doesn't even start) Running desktop with only a plain twm (no gnome-shell3 - broken to unusability as well). Happened with just some mouse movement. Might be related to https://bugzilla.redhat.com/show_bug.cgi?id=753703 My HW: Lenovo T61, gma965, 4GB, x86_64 Zdenek [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [drm:init_ring_common] *ERROR* render ring initialization failed ctl head tail start [drm] Changing LVDS panel from (+hsync, +vsync) to (-hsync, -vsync) [ cut here ] WARNING: at drivers/gpu/drm/i915/intel_display.c:792 intel_enable_pipe+0x14a/0x150 [i915]() Hardware name: 6464CTO PLL state assertion failure (expected on, current off) Modules linked in: vfat fat isofs i915 drm_kms_helper drm i2c_algo_bit ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables tun bridge stp llc lockd sunrpc snd_hda_codec_analog cryptomgr aead arc4 crypto_algapi iwl3945 iwl_legacy mac80211 psmouse iTCO_wdt usbhid serio_raw i2c_i801 hid i2c_core snd_hda_intel snd_hda_codec cfg80211 iTCO_vendor_support e1000e snd_pcm snd_timer thinkpad_acpi snd snd_page_alloc soundcore wmi nvram binfmt_misc evdev loop virtio_net kvm_intel kvm uinput dm_mod ipv6 autofs4 pcmcia ehci_hcd uhci_hcd sdhci_pci sdhci yenta_socket mmc_core usbcore sr_mod cdrom video backlight Pid: 24480, comm: kworker/u:0 Not tainted 3.1.0-8-gba92ff5 #17 Call Trace: [8104f69f] warn_slowpath_common+0x7f/0xc0 [8104f796] warn_slowpath_fmt+0x46/0x50 [a04d32ba] intel_enable_pipe+0x14a/0x150 [i915] [a04d61f1] i9xx_crtc_mode_set+0x6f1/0xd70 [i915] [a04cc4af] intel_crtc_mode_set+0x6f/0xa0 [i915] [a0424f2c] drm_crtc_helper_set_mode+0x32c/0x4d0 [drm_kms_helper] [a04a0e10] ? i915_driver_device_is_agp+0x10/0x10 [i915] [a0425143] drm_helper_resume_force_mode+0x73/0x160 [drm_kms_helper] [a04a0e10] ? i915_driver_device_is_agp+0x10/0x10 [i915] [a049aca6] i915_reset+0x526/0x12c0 [i915] [a04a0e10] ? i915_driver_device_is_agp+0x10/0x10 [i915] [a04a0ed8] i915_error_work_func+0xc8/0x110 [i915] [81070b5b] process_one_work+0x18b/0x6e0 [81070afa] ? process_one_work+0x12a/0x6e0 [814b8221] ? retint_restore_args+0xe/0xe [8107148f] worker_thread+0x15f/0x350 [81071330] ? rescuer_thread+0x240/0x240 [81075e6b] kthread+0x9b/0xa0 [814c0534] kernel_thread_helper+0x4/0x10 [8103555c] ? finish_task_switch+0x7c/0x120 [814b7c7b] ? _raw_spin_unlock_irq+0x3b/0x60 [814b8221] ? retint_restore_args+0xe/0xe [81075dd0] ? __init_kthread_worker+0x70/0x70 [814c0530] ? gs_change+0xb/0xb ---[ end trace 63d388f543b49f36 ]--- [ cut here ] WARNING: at drivers/gpu/drm/i915/intel_display.c:916 assert_pipe+0x75/0x80 [i915]() Hardware name: 6464CTO pipe B assertion failure (expected on, current off) Modules linked in: vfat fat isofs i915 drm_kms_helper drm i2c_algo_bit ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables tun bridge stp llc lockd sunrpc snd_hda_codec_analog cryptomgr aead arc4 crypto_algapi iwl3945 iwl_legacy mac80211 psmouse iTCO_wdt usbhid serio_raw i2c_i801 hid i2c_core snd_hda_intel snd_hda_codec cfg80211 iTCO_vendor_support e1000e snd_pcm snd_timer thinkpad_acpi snd snd_page_alloc soundcore wmi nvram binfmt_misc evdev loop virtio_net kvm_intel kvm uinput dm_mod ipv6 autofs4 pcmcia ehci_hcd uhci_hcd sdhci_pci sdhci yenta_socket mmc_core usbcore sr_mod cdrom video backlight Pid: 24480, comm: kworker/u:0 Tainted: GW 3.1.0-8-gba92ff5 #17 Call Trace: [8104f69f] warn_slowpath_common+0x7f/0xc0 [8104f796] warn_slowpath_fmt+0x46/0x50 [a04cd315] assert_pipe+0x75/0x80 [i915] [a04d32f6] intel_enable_plane+0x36/0x90 [i915] [a04d622d] i9xx_crtc_mode_set+0x72d/0xd70 [i915] [a04cc4af] intel_crtc_mode_set+0x6f/0xa0 [i915] [a0424f2c] drm_crtc_helper_set_mode+0x32c/0x4d0 [drm_kms_helper] [a04a0e10] ? i915_driver_device_is_agp+0x10/0x10 [i915]
[Intel-gfx] [PATCH] drm/i915: enable semaphores on per-device defaults
We should enable semaphores on IVB by default, and on SNB in cases where
dma remapping is disabled or iommu is not enabled.
v2: adapt patch according to the feedback, and put it in line with Keith's
rc6 enabling patch.
CC: Daniel Vetter daniel.vet...@ffwll.ch
CC: Ben Widawsky b...@bwidawsk.net
CC: Keith Packard kei...@keithp.com
CC: Jesse Barnes jbar...@virtuousgeek.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42696
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40564
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38862
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c|4 ++--
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 24 +++-
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc531bb..83b2be4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -58,10 +58,10 @@ module_param_named(powersave, i915_powersave, int, 0600);
MODULE_PARM_DESC(powersave,
Enable powersavings, fbc, downclocking, etc. (default: true));
-unsigned int i915_semaphores __read_mostly = 0;
+unsigned int i915_semaphores __read_mostly = -1;
module_param_named(semaphores, i915_semaphores, int, 0600);
MODULE_PARM_DESC(semaphores,
- Use semaphores for inter-ring sync (default: false));
+ Use semaphores for inter-ring sync (default: -1 (use per-chip
defaults)));
unsigned int i915_enable_rc6 __read_mostly = 0;
module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3693e83..c19a063 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -33,6 +33,11 @@
#include i915_trace.h
#include intel_drv.h
+#ifdef CONFIG_INTEL_IOMMU
+#include linux/dma_remapping.h
+#include linux/dmar.h
+#endif
+
struct change_domains {
uint32_t invalidate_domains;
uint32_t flush_domains;
@@ -746,6 +751,23 @@ i915_gem_execbuffer_flush(struct drm_device *dev,
return 0;
}
+static bool
+intel_enable_semaphores(struct drm_device *dev)
+{
+ if (i915_semaphores = 0)
+ return i915_semaphores;
+ if (INTEL_INFO(dev)-gen = 7)
+ return 1;
+#ifdef CONFIG_INTEL_IOMMU
+ /* On gen6, we only enable semaphores if dma remapping is disabled,
+* or if there is no iommu.
+*/
+ if (INTEL_INFO(dev)-gen == 6)
+ return no_iommu || dmar_disabled;
+#endif
+ return 1;
+}
+
static int
i915_gem_execbuffer_sync_rings(struct drm_i915_gem_object *obj,
struct intel_ring_buffer *to)
@@ -758,7 +780,7 @@ i915_gem_execbuffer_sync_rings(struct drm_i915_gem_object
*obj,
return 0;
/* XXX gpu semaphores are implicated in various hard hangs on SNB */
- if (INTEL_INFO(obj-base.dev)-gen 6 || !i915_semaphores)
+ if (INTEL_INFO(obj-base.dev)-gen 6 ||
!intel_enable_semaphores(obj-base.dev))
return i915_gem_object_wait_rendering(obj);
idx = intel_ring_sync_index(from, to);
--
1.7.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: enable semaphores on per-device defaults
On Mon, 21 Nov 2011 11:03:49 -0200, Eugeni Dodonov eugeni.dodo...@intel.com wrote: We should enable semaphores on IVB by default, and on SNB in cases where dma remapping is disabled or iommu is not enabled. v2: adapt patch according to the feedback, and put it in line with Keith's rc6 enabling patch. --- static int i915_gem_execbuffer_sync_rings(struct drm_i915_gem_object *obj, struct intel_ring_buffer *to) @@ -758,7 +780,7 @@ i915_gem_execbuffer_sync_rings(struct drm_i915_gem_object *obj, return 0; /* XXX gpu semaphores are implicated in various hard hangs on SNB */ - if (INTEL_INFO(obj-base.dev)-gen 6 || !i915_semaphores) + if (INTEL_INFO(obj-base.dev)-gen 6 || !intel_enable_semaphores(obj-base.dev)) Just merge the generation check into intel_enable_semaphores(). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: enable semaphores on per-device defaults
We should enable semaphores on IVB by default, and on SNB in cases where
dma remapping is disabled or iommu is not enabled.
v2: adapt patch according to the feedback, and put it in line with Keith's
rc6 enabling patch.
v3: move the generation check into intel_enable_semaphores function, and
fix variable type for i915_semaphores.
CC: Daniel Vetter daniel.vet...@ffwll.ch
CC: Ben Widawsky b...@bwidawsk.net
CC: Keith Packard kei...@keithp.com
CC: Jesse Barnes jbar...@virtuousgeek.org
CC: Chris Wilson ch...@chris-wilson.co.uk
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42696
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40564
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38862
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c|4 +-
drivers/gpu/drm/i915/i915_drv.h|2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 29 +++-
3 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc531bb..413b30d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -58,10 +58,10 @@ module_param_named(powersave, i915_powersave, int, 0600);
MODULE_PARM_DESC(powersave,
Enable powersavings, fbc, downclocking, etc. (default: true));
-unsigned int i915_semaphores __read_mostly = 0;
+int i915_semaphores __read_mostly = -1;
module_param_named(semaphores, i915_semaphores, int, 0600);
MODULE_PARM_DESC(semaphores,
- Use semaphores for inter-ring sync (default: false));
+ Use semaphores for inter-ring sync (default: -1 (use per-chip
defaults)));
unsigned int i915_enable_rc6 __read_mostly = 0;
module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0600);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 06a37f4..561e67d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -997,7 +997,7 @@ extern int i915_max_ioctl;
extern unsigned int i915_fbpercrtc __always_unused;
extern int i915_panel_ignore_lid __read_mostly;
extern unsigned int i915_powersave __read_mostly;
-extern unsigned int i915_semaphores __read_mostly;
+extern int i915_semaphores __read_mostly;
extern unsigned int i915_lvds_downclock __read_mostly;
extern unsigned int i915_panel_use_ssc __read_mostly;
extern int i915_vbt_sdvo_panel_type __read_mostly;
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3693e83..0a9778c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -33,6 +33,11 @@
#include i915_trace.h
#include intel_drv.h
+#ifdef CONFIG_INTEL_IOMMU
+#include linux/dma_remapping.h
+#include linux/dmar.h
+#endif
+
struct change_domains {
uint32_t invalidate_domains;
uint32_t flush_domains;
@@ -746,6 +751,28 @@ i915_gem_execbuffer_flush(struct drm_device *dev,
return 0;
}
+static bool
+intel_enable_semaphores(struct drm_device *dev)
+{
+ if (INTEL_INFO(dev)-gen 6)
+ return 0;
+
+ if (i915_semaphores = 0)
+ return i915_semaphores;
+
+ if (INTEL_INFO(dev)-gen = 7)
+ return 1;
+#ifdef CONFIG_INTEL_IOMMU
+ /* On gen6, we only enable semaphores if dma remapping is disabled,
+* or if there is no iommu.
+*/
+ if (INTEL_INFO(dev)-gen == 6)
+ return no_iommu || dmar_disabled;
+#endif
+
+ return 1;
+}
+
static int
i915_gem_execbuffer_sync_rings(struct drm_i915_gem_object *obj,
struct intel_ring_buffer *to)
@@ -758,7 +785,7 @@ i915_gem_execbuffer_sync_rings(struct drm_i915_gem_object
*obj,
return 0;
/* XXX gpu semaphores are implicated in various hard hangs on SNB */
- if (INTEL_INFO(obj-base.dev)-gen 6 || !i915_semaphores)
+ if (!intel_enable_semaphores(obj-base.dev))
return i915_gem_object_wait_rendering(obj);
idx = intel_ring_sync_index(from, to);
--
1.7.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: allow per-device fbc to work with default settings
The change which added support for default settings for fbc has not
changed the variable type of i915_enable_fbc from unsigned int to int. So
we were unable to get into the default ('-1') state with the default
settings.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 413b30d..1a999f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -68,7 +68,7 @@ module_param_named(i915_enable_rc6, i915_enable_rc6, int,
0600);
MODULE_PARM_DESC(i915_enable_rc6,
Enable power-saving render C-state 6 (default: true));
-unsigned int i915_enable_fbc __read_mostly = -1;
+int i915_enable_fbc __read_mostly = -1;
module_param_named(i915_enable_fbc, i915_enable_fbc, int, 0600);
MODULE_PARM_DESC(i915_enable_fbc,
Enable frame buffer compression for power savings
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 561e67d..57275ff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1002,7 +1002,7 @@ extern unsigned int i915_lvds_downclock __read_mostly;
extern unsigned int i915_panel_use_ssc __read_mostly;
extern int i915_vbt_sdvo_panel_type __read_mostly;
extern unsigned int i915_enable_rc6 __read_mostly;
-extern unsigned int i915_enable_fbc __read_mostly;
+extern int i915_enable_fbc __read_mostly;
extern bool i915_enable_hangcheck __read_mostly;
extern int i915_suspend(struct drm_device *dev, pm_message_t state);
--
1.7.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: enable semaphores on per-device defaults
On Mon, 21 Nov 2011 11:22:09 -0200, Eugeni Dodonov eugeni.dodo...@intel.com
wrote:
We should enable semaphores on IVB by default, and on SNB in cases where
dma remapping is disabled or iommu is not enabled.
v2: adapt patch according to the feedback, and put it in line with Keith's
rc6 enabling patch.
v3: move the generation check into intel_enable_semaphores function, and
fix variable type for i915_semaphores.
CC: Daniel Vetter daniel.vet...@ffwll.ch
CC: Ben Widawsky b...@bwidawsk.net
CC: Keith Packard kei...@keithp.com
CC: Jesse Barnes jbar...@virtuousgeek.org
CC: Chris Wilson ch...@chris-wilson.co.uk
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42696
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40564
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41353
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38862
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
+static bool
+intel_enable_semaphores(struct drm_device *dev)
+{
+ if (INTEL_INFO(dev)-gen 6)
+ return 0;
+
+ if (i915_semaphores = 0)
+ return i915_semaphores;
+
+ if (INTEL_INFO(dev)-gen = 7)
+ return 1;
+#ifdef CONFIG_INTEL_IOMMU
+ /* On gen6, we only enable semaphores if dma remapping is disabled,
+ * or if there is no iommu.
+ */
+ if (INTEL_INFO(dev)-gen == 6)
+ return no_iommu || dmar_disabled;
+#endif
+
+ return 1;
+}
Now this function can be written more compactly by just removing the
gen = 7 check. Otherwise,
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: allow per-device fbc to work with default settings
On Mon, 21 Nov 2011 11:22:10 -0200, Eugeni Dodonov eugeni.dodo...@intel.com
wrote:
The change which added support for default settings for fbc has not
changed the variable type of i915_enable_fbc from unsigned int to int. So
we were unable to get into the default ('-1') state with the default
settings.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] WARNING: at drivers/gpu/drm/i915/intel_display.c:792
2011/11/21 Zdenek Kabelac zdenek.kabe...@gmail.com: Hi My Xorg server on rawhide machine is giving me sudden X lockups with 3.1 kernel. There might be couple issue related together as rawhide is now using some experimental Xorg server - but the message from kernel is a bit scary - so reposting to lkml as well. xorg-x11-server-Xorg-1.11.99.1-6.2009.fc17.x86_64 git intel driver: 3b9479dc39d32fd97f80c1e5e0fac67d36ee5e40 drm version (a bit older): 8d055890d90c3d92647e3d8b98d32630ef87c2c8 (since current Fedora rawhide intel driver is so much broken it doesn't even start) It's worth to mention - it happens also with kernel 3.0 and the latest updated libdrm (ca4971292cf99e0063416cd1c3467af94637bf2b) The processing of mouse event seems to be always mandatory (i.e. it blacks LCD with some mouse movement). Zdenek ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote: [snip the patch] Bikeshed, but I would much prefer a #define for the swizzle bit/cacheline size. I've looked at this stuff way too long, so I'm biased, but 64 = cacheline = dram fetch size = 1 64 feels about as natural for me as 4096 = PAGE_SIZE ... [snip the patch] I must be missing something obvious here... Can you explain how this can possibly be considered safe without holding struct_mutex? That's the reason why the commit msg goes through every case and explains why I think it's safe. The large thing here is that we need to drop the mutex when calling copy_*_user (at least in the non-atomic slow-paths) because otherwise we might deadlock with our own pagefault handler. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver
On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang fengguang...@intel.com wrote: On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE or DP_AUDIO_OUTPUT_ENABLE accordingly. So that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. A new callback -hotplug() is added to struct drm_connector_funcs which will be called immediately after -detect() knowing that the monitor is either plugged or unplugged. It's noticed that X may not call -mode_set() at monitor hot plug, so it's necessary to call drm_edid_to_eld() earlier at -detect() time rather than in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD in -hotplug. The X environment will eventually call mode_set when the user environment decides to use the monitor. Any audio bits can, and should, await the user's choice of a video mode before choosing the audio format to use. We should not be adding eld information until the monitor is in use. -- keith.pack...@intel.com pgpPp1TwzY1py.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: hot removal notification to HDMI audio driver
On Mon, 21 Nov 2011 19:05:38 +0800, Wu Fengguang fengguang...@intel.com wrote: Ah I got it. I'm running debian+fluxbox w/o those fancy features... Then you can manually run the 'xrandr' command to configure the new monitor as desired, at which point the kernel mode_set function will be called. -- keith.pack...@intel.com pgpAQyXA2WjTT.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
On Mon, Nov 21, 2011 at 05:02:44PM +0100, Daniel Vetter wrote: On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote: [snip the patch] Bikeshed, but I would much prefer a #define for the swizzle bit/cacheline size. I've looked at this stuff way too long, so I'm biased, but 64 = cacheline = dram fetch size = 1 64 feels about as natural for me as 4096 = PAGE_SIZE ... [snip the patch] I must be missing something obvious here... Can you explain how this can possibly be considered safe without holding struct_mutex? That's the reason why the commit msg goes through every case and explains why I think it's safe. The large thing here is that we need to drop the mutex when calling copy_*_user (at least in the non-atomic slow-paths) because otherwise we might deadlock with our own pagefault handler. -Daniel The part about dropping struct_mutex is clear to me. The bit that I'm missing, I just don't see how you guarantee the page you're reading from (assuming it's a GTT mmapped page) doesn't get moved from out under you. For instance if the page isn't there when you do the initial __copy_from_user, it will get faulted in... cool - but what if somewhere in that loop the object gets swapped out and something else is put in it's place? How is that prevented? Sorry if it's a stupid question, I just don't get it. Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix invalid backpanel values for GEN3 or older chips
On Sun, 20 Nov 2011 12:22:50 +0100, Takashi Iwai ti...@suse.de wrote: So, writing bit-0 caused a problem, as it seems. Thanks. I've noted that in the patch message. -- keith.pack...@intel.com pgpCXCnhRKCYp.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/13] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user
On Mon, Nov 21, 2011 at 09:55:07AM -0800, Ben Widawsky wrote: On Mon, Nov 21, 2011 at 05:02:44PM +0100, Daniel Vetter wrote: On Sun, Nov 20, 2011 at 09:56:32PM -0800, Ben Widawsky wrote: [snip the patch] Bikeshed, but I would much prefer a #define for the swizzle bit/cacheline size. I've looked at this stuff way too long, so I'm biased, but 64 = cacheline = dram fetch size = 1 64 feels about as natural for me as 4096 = PAGE_SIZE ... [snip the patch] I must be missing something obvious here... Can you explain how this can possibly be considered safe without holding struct_mutex? That's the reason why the commit msg goes through every case and explains why I think it's safe. The large thing here is that we need to drop the mutex when calling copy_*_user (at least in the non-atomic slow-paths) because otherwise we might deadlock with our own pagefault handler. -Daniel The part about dropping struct_mutex is clear to me. The bit that I'm missing, I just don't see how you guarantee the page you're reading from (assuming it's a GTT mmapped page) doesn't get moved from out under you. For instance if the page isn't there when you do the initial __copy_from_user, it will get faulted in... cool - but what if somewhere in that loop the object gets swapped out and something else is put in it's place? How is that prevented? Sorry if it's a stupid question, I just don't get it. Ben Okay, I got what I was missing from IRC. Anytime the object is unmapped we shoot down the userspace mapping. I couldn't find it in the code, but it turned out to be right in front of me. Reviewed-by: Ben Widawsky b...@bwidawsk.net ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/13] drm: add helper to clflush a virtual address range
On Sun, Nov 06, 2011 at 08:13:53PM +0100, Daniel Vetter wrote:
Useful when the page is already mapped to copy date in/out.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_cache.c | 23 +++
include/drm/drmP.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 0e3bd5b..502771a 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -97,3 +97,26 @@ drm_clflush_pages(struct page *pages[], unsigned long
num_pages)
#endif
}
EXPORT_SYMBOL(drm_clflush_pages);
+
+void
+drm_clflush_virt_range(char *addr, unsigned long length)
+{
+#if defined(CONFIG_X86)
+ if (cpu_has_clflush) {
+ char *end = addr + length;
+ mb();
+ for (; addr end; addr += boot_cpu_data.x86_clflush_size)
+ clflush(addr);
+ clflush(end - 1);
+ mb();
+ return;
+ }
+
+ if (on_each_cpu(drm_clflush_ipi_handler, NULL, 1) != 0)
+ printk(KERN_ERR Timed out waiting for cache flush.\n);
+#else
+ printk(KERN_ERR Architecture has no drm_cache.c support\n);
+ WARN_ON_ONCE(1);
+#endif
+}
+EXPORT_SYMBOL(drm_clflush_virt_range);
I'd feel more comfortable with a BUG_ON(irqs_disabled()); before the
IPI... though I don't even know how many platforms that actually
pertains to (if any).
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: re-enable semaphores by default
On Thu, Nov 17, 2011 at 1:22 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Oops, sorry for wasting your time, wrong branch. Can you try the for-poland one? And also please try what happens when enabling the iommu. for-poland with semaphores, rc6, and iommu on seems to work. I'm sending this email from that kernel right now :) --Andy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3 v2] drm/i915: hot plug/unplug notification to HDMI audio driver
On Tue, Nov 22, 2011 at 12:55:43AM +0800, Keith Packard wrote: On Mon, 21 Nov 2011 14:37:49 +0800, Wu Fengguang fengguang...@intel.com wrote: On monitor hot plug/unplug, update ELD and set/clear SDVO_AUDIO_ENABLE or DP_AUDIO_OUTPUT_ENABLE accordingly. So that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. A new callback -hotplug() is added to struct drm_connector_funcs which will be called immediately after -detect() knowing that the monitor is either plugged or unplugged. It's noticed that X may not call -mode_set() at monitor hot plug, so it's necessary to call drm_edid_to_eld() earlier at -detect() time rather than in intel_ddc_get_modes(), so that intel_write_eld() can see the new ELD in -hotplug. The X environment will eventually call mode_set when the user environment decides to use the monitor. Any audio bits can, and should, await the user's choice of a video mode before choosing the audio format to use. We should not be adding eld information until the monitor is in use. Yeah. I just tested the full gnome desktop and find it behave like the KMS console: 1) -mode_set will be called 2) crtc is 0 in intel_hdmi_hotplug(), hence skipping the ELD code there So the v3 patch will behave equally well on KMS console, gnome desktop and bare X. Shall we just use it, or go back and use the original -hot_remove patch? Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
