linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE
@ 2013-01-27 15:20 Zhang Rui
  2013-01-27 15:20 ` [RFC PATCH 2/3] ACPI: enable ACPI SCI during suspend Zhang Rui
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Zhang Rui @ 2013-01-27 15:20 UTC (permalink / raw)
  To: linux-kernel, linux-pm, linux-acpi, intel-gfx; +Cc: rjw, lenb, Zhang Rui

PM_SUSPEND_FREEZE state is a general state that
does not need any platform specific support, it equals
frozen processes + suspended devices + idle processors.

Compared with PM_SUSPEND_MEMORY,
PM_SUSPEND_FREEZE saves less power
because the system is still in a running state.
PM_SUSPEND_FREEZE has less resume latency because it does not
touch BIOS, and the processors are in idle state.

Compared with RTPM/idle,
PM_SUSPEND_FREEZE saves more power as
1. the processor has longer sleep time because processes are frozen.
   The deeper c-state the processor supports, more power saving we can get.
2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get
   more power saving from the devices that does not have good RTPM support.

This state is useful for
1) platforms that do not have STR, or have a broken STR.
2) platforms that have an extremely low power idle state,
   which can be used to replace STR.

The following describes how PM_SUSPEND_FREEZE state works.
1. echo freeze > /sys/power/state
2. the processes are frozen.
3. all the devices are suspended.
4. all the processors are blocked by a wait queue
5. all the processors idles and enters (Deep) c-state.
6. an interrupt fires.
7. a processor is woken up and handles the irq.
8. if it is a general event,
   a) the irq handler runs and quites.
   b) goto step 4.
9. if it is a real wake event, say, power button pressing, keyboard touch, mouse moving,
   a) the irq handler runs and activate the wakeup source
   b) wakeup_source_activate() notifies the wait queue.
   c) system starts resuming from PM_SUSPEND_FREEZE
10. all the devices are resumed.
11. all the processes are unfrozen.
12. system is back to working.

Known Issue:
The wakeup of this new PM_SUSPEND_FREEZE state may behave differently
from the previous suspend state.
Take ACPI platform for example, there are some GPEs that only enabled
when the system is in sleep state, to wake the system backk from S3/S4.
But we are not touching these GPEs during transition to PM_SUSPEND_FREEZE.
This means we may lose some wake event.
But on the other hand, as we do not disable all the Interrupts during
PM_SUSPEND_FREEZE, we may get some extra "wakeup" Interrupts, that are
not available for S3/S4.

The patches has been tested on an old Sony laptop, and here are the results:

Average Power:
1. RPTM/idle for half an hour:
   14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W
2. Freeze for half an hour:
   11W, 10.4W, 9.4W, 11.3W 10.5W
3. RTPM/idle for three hours:
   11.6W
4. Freeze for three hours:
   10W
5. Suspend to Memory:
   0.5~0.9W

Average Resume Latency:
1. RTPM/idle with a black screen: (From pressing keyboard to screen back)
   Less than 0.2s
2. Freeze: (From pressing power button to screen back)
   2.50s
3. Suspend to Memory: (From pressing power button to screen back)
   4.33s

>From the results, we can see that all the platforms should benefit from
this patch, even if it does not have Low Power S0.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
---
 drivers/base/power/wakeup.c |    6 ++++
 include/linux/suspend.h     |    5 +++-
 kernel/power/main.c         |    2 +-
 kernel/power/suspend.c      |   69 +++++++++++++++++++++++++++++++++++--------
 4 files changed, 67 insertions(+), 15 deletions(-)

diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index e6ee5e8..79715e7 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -382,6 +382,12 @@ static void wakeup_source_activate(struct wakeup_source *ws)
 {
 	unsigned int cec;
 
+	/*
+	 * active wakeup source should bring the system
+	 * out of PM_SUSPEND_FREEZE state
+	 */
+	freeze_wake();
+
 	ws->active = true;
 	ws->active_count++;
 	ws->last_time = ktime_get();
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 0c808d7..7420ab5 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -34,8 +34,10 @@ static inline void pm_restore_console(void)
 typedef int __bitwise suspend_state_t;
 
 #define PM_SUSPEND_ON		((__force suspend_state_t) 0)
-#define PM_SUSPEND_STANDBY	((__force suspend_state_t) 1)
+#define PM_SUSPEND_FREEZE	((__force suspend_state_t) 1)
+#define PM_SUSPEND_STANDBY	((__force suspend_state_t) 2)
 #define PM_SUSPEND_MEM		((__force suspend_state_t) 3)
+#define PM_SUSPEND_MIN		PM_SUSPEND_FREEZE
 #define PM_SUSPEND_MAX		((__force suspend_state_t) 4)
 
 enum suspend_stat_step {
@@ -192,6 +194,7 @@ struct platform_suspend_ops {
  */
 extern void suspend_set_ops(const struct platform_suspend_ops *ops);
 extern int suspend_valid_only_mem(suspend_state_t state);
+extern void freeze_wake(void);
 
 /**
  * arch_suspend_disable_irqs - disable IRQs for suspend
diff --git a/kernel/power/main.c b/kernel/power/main.c
index 1c16f91..b1c26a9 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -313,7 +313,7 @@ static ssize_t state_show(struct kobject *kobj, struct kobj_attribute *attr,
 static suspend_state_t decode_state(const char *buf, size_t n)
 {
 #ifdef CONFIG_SUSPEND
-	suspend_state_t state = PM_SUSPEND_STANDBY;
+	suspend_state_t state = PM_SUSPEND_MIN;
 	const char * const *s;
 #endif
 	char *p;
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index c8b7446..d4feda0 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -30,12 +30,38 @@
 #include "power.h"
 
 const char *const pm_states[PM_SUSPEND_MAX] = {
+	[PM_SUSPEND_FREEZE]	= "freeze",
 	[PM_SUSPEND_STANDBY]	= "standby",
 	[PM_SUSPEND_MEM]	= "mem",
 };
 
 static const struct platform_suspend_ops *suspend_ops;
 
+static bool need_suspend_ops(suspend_state_t state)
+{
+	return !!(state > PM_SUSPEND_FREEZE);
+}
+
+static DECLARE_WAIT_QUEUE_HEAD(suspend_freeze_wait_head);
+static bool suspend_freeze_wake;
+
+static void freeze_begin(void)
+{
+	suspend_freeze_wake = false;
+}
+
+static void freeze_enter(void)
+{
+	wait_event(suspend_freeze_wait_head, suspend_freeze_wake);
+}
+
+void freeze_wake(void)
+{
+	suspend_freeze_wake = true;
+	wake_up(&suspend_freeze_wait_head);
+}
+EXPORT_SYMBOL_GPL(freeze_wake);
+
 /**
  * suspend_set_ops - Set the global suspend method table.
  * @ops: Suspend operations to use.
@@ -50,8 +76,11 @@ EXPORT_SYMBOL_GPL(suspend_set_ops);
 
 bool valid_state(suspend_state_t state)
 {
+	if (state == PM_SUSPEND_FREEZE)
+		return true;
 	/*
-	 * All states need lowlevel support and need to be valid to the lowlevel
+	 * PM_SUSPEND_STANDBY and PM_SUSPEND_MEMORY states need lowlevel
+	 * support and need to be valid to the lowlevel
 	 * implementation, no valid callback implies that none are valid.
 	 */
 	return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
@@ -89,11 +118,11 @@ static int suspend_test(int level)
  * hibernation).  Run suspend notifiers, allocate the "suspend" console and
  * freeze processes.
  */
-static int suspend_prepare(void)
+static int suspend_prepare(suspend_state_t state)
 {
 	int error;
 
-	if (!suspend_ops || !suspend_ops->enter)
+	if (need_suspend_ops(state) && (!suspend_ops || !suspend_ops->enter))
 		return -EPERM;
 
 	pm_prepare_console();
@@ -137,7 +166,7 @@ static int suspend_enter(suspend_state_t state, bool *wakeup)
 {
 	int error;
 
-	if (suspend_ops->prepare) {
+	if (need_suspend_ops(state) && suspend_ops->prepare) {
 		error = suspend_ops->prepare();
 		if (error)
 			goto Platform_finish;
@@ -149,12 +178,23 @@ static int suspend_enter(suspend_state_t state, bool *wakeup)
 		goto Platform_finish;
 	}
 
-	if (suspend_ops->prepare_late) {
+	if (need_suspend_ops(state) && suspend_ops->prepare_late) {
 		error = suspend_ops->prepare_late();
 		if (error)
 			goto Platform_wake;
 	}
 
+	/*
+	 * PM_SUSPEND_FREEZE equals
+	 * frozen processes + suspended devices + idle processors.
+	 * Thus we should invoke freeze_enter() soon after
+	 * all the devices are suspended.
+	 */
+	if (state == PM_SUSPEND_FREEZE) {
+		freeze_enter();
+		goto Platform_wake;
+	}
+
 	if (suspend_test(TEST_PLATFORM))
 		goto Platform_wake;
 
@@ -182,13 +222,13 @@ static int suspend_enter(suspend_state_t state, bool *wakeup)
 	enable_nonboot_cpus();
 
  Platform_wake:
-	if (suspend_ops->wake)
+	if (need_suspend_ops(state) && suspend_ops->wake)
 		suspend_ops->wake();
 
 	dpm_resume_start(PMSG_RESUME);
 
  Platform_finish:
-	if (suspend_ops->finish)
+	if (need_suspend_ops(state) && suspend_ops->finish)
 		suspend_ops->finish();
 
 	return error;
@@ -203,11 +243,11 @@ int suspend_devices_and_enter(suspend_state_t state)
 	int error;
 	bool wakeup = false;
 
-	if (!suspend_ops)
+	if (need_suspend_ops(state) && !suspend_ops)
 		return -ENOSYS;
 
 	trace_machine_suspend(state);
-	if (suspend_ops->begin) {
+	if (need_suspend_ops(state) && suspend_ops->begin) {
 		error = suspend_ops->begin(state);
 		if (error)
 			goto Close;
@@ -226,7 +266,7 @@ int suspend_devices_and_enter(suspend_state_t state)
 
 	do {
 		error = suspend_enter(state, &wakeup);
-	} while (!error && !wakeup
+	} while (!error && !wakeup && need_suspend_ops(state)
 		&& suspend_ops->suspend_again && suspend_ops->suspend_again());
 
  Resume_devices:
@@ -236,13 +276,13 @@ int suspend_devices_and_enter(suspend_state_t state)
 	ftrace_start();
 	resume_console();
  Close:
-	if (suspend_ops->end)
+	if (need_suspend_ops(state) && suspend_ops->end)
 		suspend_ops->end();
 	trace_machine_suspend(PWR_EVENT_EXIT);
 	return error;
 
  Recover_platform:
-	if (suspend_ops->recover)
+	if (need_suspend_ops(state) && suspend_ops->recover)
 		suspend_ops->recover();
 	goto Resume_devices;
 }
@@ -278,12 +318,15 @@ static int enter_state(suspend_state_t state)
 	if (!mutex_trylock(&pm_mutex))
 		return -EBUSY;
 
+	if (state == PM_SUSPEND_FREEZE)
+		freeze_begin();
+
 	printk(KERN_INFO "PM: Syncing filesystems ... ");
 	sys_sync();
 	printk("done.\n");
 
 	pr_debug("PM: Preparing system for %s sleep\n", pm_states[state]);
-	error = suspend_prepare();
+	error = suspend_prepare(state);
 	if (error)
 		goto Unlock;
 
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [RFC PATCH 2/3] ACPI: enable ACPI SCI during suspend
  2013-01-27 15:20 [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE Zhang Rui
@ 2013-01-27 15:20 ` Zhang Rui
  2013-01-27 15:21 ` [RFC PATCH 3/3] i915: ignore lid open event when resuming Zhang Rui
  2013-01-29  2:05 ` [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE Andreas Mohr
  2 siblings, 0 replies; 12+ messages in thread
From: Zhang Rui @ 2013-01-27 15:20 UTC (permalink / raw)
  To: linux-kernel, linux-pm, linux-acpi, intel-gfx; +Cc: rjw, lenb, Zhang Rui

Enable ACPI SCI during suspend so that SCI can be used
as wake events for PM_SUSPEND_FREEZE.

For S3/S4 transition,
We disable all GPEs in suspend_ops->prepare_late() to
fix a problem that GPEs may trigger SCI  before
arch_suspend_disable_irqs() is run.
So it is safe to leave the SCI enabled until
arch_suspend_irq_disable() is run.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
---
 drivers/acpi/osl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 3ff2678..3adeb10 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -787,7 +787,7 @@ acpi_os_install_interrupt_handler(u32 gsi, acpi_osd_handler handler,
 
 	acpi_irq_handler = handler;
 	acpi_irq_context = context;
-	if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) {
+	if (request_irq(irq, acpi_irq, IRQF_SHARED | IRQF_NO_SUSPEND, "acpi", acpi_irq)) {
 		printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
 		acpi_irq_handler = NULL;
 		return AE_NOT_ACQUIRED;
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [RFC PATCH 3/3] i915: ignore lid open event when resuming
  2013-01-27 15:20 [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE Zhang Rui
  2013-01-27 15:20 ` [RFC PATCH 2/3] ACPI: enable ACPI SCI during suspend Zhang Rui
@ 2013-01-27 15:21 ` Zhang Rui
  2013-01-27 15:45   ` [Intel-gfx] " Daniel Vetter
  2013-01-29  2:05 ` [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE Andreas Mohr
  2 siblings, 1 reply; 12+ messages in thread
From: Zhang Rui @ 2013-01-27 15:21 UTC (permalink / raw)
  To: linux-kernel, linux-pm, linux-acpi, intel-gfx; +Cc: rjw, lenb, Zhang Rui

i915 driver needs to do modeset when
1. system resumes from sleep
2. lid is opened

In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
thus it is the i915_resume code does the modeset rather than intel_lid_notify().

In PM_SUSPEND_FREEZE state, system is still resposive to the lid events.
1. When we close the lid in Freeze state, intel_lid_notify() sets modeset_on_lid.
2. When we reopen the lid, intel_lid_notify() will do a modeset,
   before the system is resumed.

here is the error log,

[92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x184/0x190 [i915]()
[92146.548076] Hardware name: VGN-Z540N
[92146.548078] pipe_off wait timed out
[92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal e1000e
[92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: G        W    3.8.0-rc3-s0i3-v3-test+ #9
[92146.548175] Call Trace:
[92146.548189]  [<c10378e2>] warn_slowpath_common+0x72/0xa0
[92146.548227]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548263]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548270]  [<c10379b3>] warn_slowpath_fmt+0x33/0x40
[92146.548307]  [<f86398b4>] intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548344]  [<f86399c2>] intel_disable_pipe+0x102/0x190 [i915]
[92146.548380]  [<f8639ea4>] ? intel_disable_plane+0x64/0x80 [i915]
[92146.548417]  [<f8639f7c>] i9xx_crtc_disable+0xbc/0x150 [i915]
[92146.548456]  [<f863ebee>] intel_crtc_update_dpms+0x5e/0x90 [i915]
[92146.548493]  [<f86437cf>] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
[92146.548535]  [<f8645b0b>] intel_lid_notify+0x9b/0xc0 [i915]
[92146.548543]  [<c15610d3>] notifier_call_chain+0x43/0x60
[92146.548550]  [<c105d1e1>] __blocking_notifier_call_chain+0x41/0x80
[92146.548556]  [<c105d23f>] blocking_notifier_call_chain+0x1f/0x30
[92146.548563]  [<c131a684>] acpi_lid_send_state+0x78/0xa4
[92146.548569]  [<c131aa9e>] acpi_button_notify+0x3b/0xf1
[92146.548577]  [<c12df56a>] ? acpi_os_execute+0x17/0x19
[92146.548582]  [<c12e591a>] ? acpi_ec_sync_query+0xa5/0xbc
[92146.548589]  [<c12e2b82>] acpi_device_notify+0x16/0x18
[92146.548595]  [<c12f4904>] acpi_ev_notify_dispatch+0x38/0x4f
[92146.548600]  [<c12df0e8>] acpi_os_execute_deferred+0x20/0x2b
[92146.548607]  [<c1051208>] process_one_work+0x128/0x3f0
[92146.548613]  [<c1564f73>] ? common_interrupt+0x33/0x38
[92146.548618]  [<c104f8c0>] ? wake_up_worker+0x30/0x30
[92146.548624]  [<c12df0c8>] ? acpi_os_wait_events_complete+0x1e/0x1e
[92146.548629]  [<c10524f9>] worker_thread+0x119/0x3b0
[92146.548634]  [<c10523e0>] ? manage_workers+0x240/0x240
[92146.548640]  [<c1056e84>] kthread+0x94/0xa0
[92146.548647]  [<c1060000>] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0
[92146.548652]  [<c15649b7>] ret_from_kernel_thread+0x1b/0x28
[92146.548658]  [<c1056df0>] ? kthread_create_on_node+0xc0/0xc0

so I'd like to use tristate for modeset_on_lid instead of bool.
-1: ingore all the lid events.
0:  do not do modeset when there is a lid-open event.
1:  do modeset when there is a lid-open event.
In this way, only device resume code will do modeset in a suspend/resume cycle.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.c   |    4 ++--
 drivers/gpu/drm/i915/i915_drv.h   |    2 +-
 drivers/gpu/drm/i915/intel_lvds.c |    2 ++
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1172658..d7613cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -492,8 +492,8 @@ static int i915_drm_freeze(struct drm_device *dev)
 
 	intel_opregion_fini(dev);
 
-	/* Modeset on resume, not lid events */
-	dev_priv->modeset_on_lid = 0;
+	/* Modeset on resume, ignore lid events */
+	dev_priv->modeset_on_lid = -1;
 
 	console_lock();
 	intel_fbdev_set_suspend(dev, 1);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ed30595..3fec498 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -748,7 +748,7 @@ typedef struct drm_i915_private {
 	unsigned long quirks;
 
 	/* Register state */
-	bool modeset_on_lid;
+	int modeset_on_lid;	/* -1: invalid, 0: no modeset, 1: do modeset */
 
 	struct {
 		/** Bridge to intel-gtt-ko */
diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index 17aee74..4ddae6d 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -512,6 +512,8 @@ static int intel_lid_notify(struct notifier_block *nb, unsigned long val,
 	if (dev->switch_power_state != DRM_SWITCH_POWER_ON)
 		return NOTIFY_OK;
 
+	if (dev_priv->modeset_on_lid == -1)
+		return NOTIFY_OK;
 	/*
 	 * check and update the status of LVDS connector after receiving
 	 * the LID nofication event.
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming
  2013-01-27 15:21 ` [RFC PATCH 3/3] i915: ignore lid open event when resuming Zhang Rui
@ 2013-01-27 15:45   ` Daniel Vetter
  2013-01-27 22:21     ` Rafael J. Wysocki
  2013-01-28  2:36     ` Zhang Rui
  0 siblings, 2 replies; 12+ messages in thread
From: Daniel Vetter @ 2013-01-27 15:45 UTC (permalink / raw)
  To: Zhang Rui; +Cc: linux-kernel, linux-pm, linux-acpi, intel-gfx, rjw, lenb

On Sun, Jan 27, 2013 at 4:21 PM, Zhang Rui <rui.zhang@intel.com> wrote:
> i915 driver needs to do modeset when
> 1. system resumes from sleep
> 2. lid is opened
>
> In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
> thus it is the i915_resume code does the modeset rather than intel_lid_notify().
>
> In PM_SUSPEND_FREEZE state, system is still resposive to the lid events.
> 1. When we close the lid in Freeze state, intel_lid_notify() sets modeset_on_lid.
> 2. When we reopen the lid, intel_lid_notify() will do a modeset,
>    before the system is resumed.
>
> here is the error log,
>
> [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x184/0x190 [i915]()
> [92146.548076] Hardware name: VGN-Z540N
> [92146.548078] pipe_off wait timed out
> [92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal e1000e
> [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: G        W    3.8.0-rc3-s0i3-v3-test+ #9
> [92146.548175] Call Trace:
> [92146.548189]  [<c10378e2>] warn_slowpath_common+0x72/0xa0
> [92146.548227]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
> [92146.548263]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
> [92146.548270]  [<c10379b3>] warn_slowpath_fmt+0x33/0x40
> [92146.548307]  [<f86398b4>] intel_wait_for_pipe_off+0x184/0x190 [i915]
> [92146.548344]  [<f86399c2>] intel_disable_pipe+0x102/0x190 [i915]
> [92146.548380]  [<f8639ea4>] ? intel_disable_plane+0x64/0x80 [i915]
> [92146.548417]  [<f8639f7c>] i9xx_crtc_disable+0xbc/0x150 [i915]
> [92146.548456]  [<f863ebee>] intel_crtc_update_dpms+0x5e/0x90 [i915]
> [92146.548493]  [<f86437cf>] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
> [92146.548535]  [<f8645b0b>] intel_lid_notify+0x9b/0xc0 [i915]
> [92146.548543]  [<c15610d3>] notifier_call_chain+0x43/0x60
> [92146.548550]  [<c105d1e1>] __blocking_notifier_call_chain+0x41/0x80
> [92146.548556]  [<c105d23f>] blocking_notifier_call_chain+0x1f/0x30
> [92146.548563]  [<c131a684>] acpi_lid_send_state+0x78/0xa4
> [92146.548569]  [<c131aa9e>] acpi_button_notify+0x3b/0xf1
> [92146.548577]  [<c12df56a>] ? acpi_os_execute+0x17/0x19
> [92146.548582]  [<c12e591a>] ? acpi_ec_sync_query+0xa5/0xbc
> [92146.548589]  [<c12e2b82>] acpi_device_notify+0x16/0x18
> [92146.548595]  [<c12f4904>] acpi_ev_notify_dispatch+0x38/0x4f
> [92146.548600]  [<c12df0e8>] acpi_os_execute_deferred+0x20/0x2b
> [92146.548607]  [<c1051208>] process_one_work+0x128/0x3f0
> [92146.548613]  [<c1564f73>] ? common_interrupt+0x33/0x38
> [92146.548618]  [<c104f8c0>] ? wake_up_worker+0x30/0x30
> [92146.548624]  [<c12df0c8>] ? acpi_os_wait_events_complete+0x1e/0x1e
> [92146.548629]  [<c10524f9>] worker_thread+0x119/0x3b0
> [92146.548634]  [<c10523e0>] ? manage_workers+0x240/0x240
> [92146.548640]  [<c1056e84>] kthread+0x94/0xa0
> [92146.548647]  [<c1060000>] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0
> [92146.548652]  [<c15649b7>] ret_from_kernel_thread+0x1b/0x28
> [92146.548658]  [<c1056df0>] ? kthread_create_on_node+0xc0/0xc0
>
> so I'd like to use tristate for modeset_on_lid instead of bool.
> -1: ingore all the lid events.
> 0:  do not do modeset when there is a lid-open event.
> 1:  do modeset when there is a lid-open event.
> In this way, only device resume code will do modeset in a suspend/resume cycle.
>
> Signed-off-by: Zhang Rui <rui.zhang@intel.com>

Given that this essentially requires users to manually set this module
option to make stuff work I don't like this.

I see a few possible options:
- plug the races between all the different parts - I've never really
understood why acpi sends us events before the resume code has
completed ... If that's indeed intentional, we could delay the
handling a bit until at least the i915 resume code completed.
- Judging from the diff context you're not on the latest 3.8-rc
codebase - we've applied a few fixes to this lid hack recently. Please
retest on a kernel with

commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Nov 23 18:16:34 2012 +0100

    drm/i915: force restore on lid open

- This lid hack is only required since a few moronic BIOS
implementations touch the display hw state behind our backs. On
platforms with OpRegion support this shouldn't be the case any longer
(which means pretty much everything shipped in the last few years), so
we could conditionalize this hack on that (e.g. check out the existing
dev_priv->opregion.header check in the i915_resume function in
i915_drv.c in drm-next).

Yours, Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.c   |    4 ++--
>  drivers/gpu/drm/i915/i915_drv.h   |    2 +-
>  drivers/gpu/drm/i915/intel_lvds.c |    2 ++
>  3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1172658..d7613cb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -492,8 +492,8 @@ static int i915_drm_freeze(struct drm_device *dev)
>
>         intel_opregion_fini(dev);
>
> -       /* Modeset on resume, not lid events */
> -       dev_priv->modeset_on_lid = 0;
> +       /* Modeset on resume, ignore lid events */
> +       dev_priv->modeset_on_lid = -1;
>
>         console_lock();
>         intel_fbdev_set_suspend(dev, 1);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ed30595..3fec498 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -748,7 +748,7 @@ typedef struct drm_i915_private {
>         unsigned long quirks;
>
>         /* Register state */
> -       bool modeset_on_lid;
> +       int modeset_on_lid;     /* -1: invalid, 0: no modeset, 1: do modeset */
>
>         struct {
>                 /** Bridge to intel-gtt-ko */
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
> index 17aee74..4ddae6d 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -512,6 +512,8 @@ static int intel_lid_notify(struct notifier_block *nb, unsigned long val,
>         if (dev->switch_power_state != DRM_SWITCH_POWER_ON)
>                 return NOTIFY_OK;
>
> +       if (dev_priv->modeset_on_lid == -1)
> +               return NOTIFY_OK;
>         /*
>          * check and update the status of LVDS connector after receiving
>          * the LID nofication event.
> --
> 1.7.9.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming
  2013-01-27 15:45   ` [Intel-gfx] " Daniel Vetter
@ 2013-01-27 22:21     ` Rafael J. Wysocki
  2013-01-27 23:21       ` Daniel Vetter
  2013-01-28  2:36     ` Zhang Rui
  1 sibling, 1 reply; 12+ messages in thread
From: Rafael J. Wysocki @ 2013-01-27 22:21 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Zhang Rui, linux-kernel, linux-pm, linux-acpi, intel-gfx, lenb

On Sunday, January 27, 2013 04:45:51 PM Daniel Vetter wrote:
> On Sun, Jan 27, 2013 at 4:21 PM, Zhang Rui <rui.zhang@intel.com> wrote:
> > i915 driver needs to do modeset when
> > 1. system resumes from sleep
> > 2. lid is opened
> >
> > In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
> > thus it is the i915_resume code does the modeset rather than intel_lid_notify().
> >
> > In PM_SUSPEND_FREEZE state, system is still resposive to the lid events.
> > 1. When we close the lid in Freeze state, intel_lid_notify() sets modeset_on_lid.
> > 2. When we reopen the lid, intel_lid_notify() will do a modeset,
> >    before the system is resumed.
> >
> > here is the error log,
> >
> > [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x184/0x190 [i915]()
> > [92146.548076] Hardware name: VGN-Z540N
> > [92146.548078] pipe_off wait timed out
> > [92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal e1000e
> > [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: G        W    3.8.0-rc3-s0i3-v3-test+ #9
> > [92146.548175] Call Trace:
> > [92146.548189]  [<c10378e2>] warn_slowpath_common+0x72/0xa0
> > [92146.548227]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
> > [92146.548263]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
> > [92146.548270]  [<c10379b3>] warn_slowpath_fmt+0x33/0x40
> > [92146.548307]  [<f86398b4>] intel_wait_for_pipe_off+0x184/0x190 [i915]
> > [92146.548344]  [<f86399c2>] intel_disable_pipe+0x102/0x190 [i915]
> > [92146.548380]  [<f8639ea4>] ? intel_disable_plane+0x64/0x80 [i915]
> > [92146.548417]  [<f8639f7c>] i9xx_crtc_disable+0xbc/0x150 [i915]
> > [92146.548456]  [<f863ebee>] intel_crtc_update_dpms+0x5e/0x90 [i915]
> > [92146.548493]  [<f86437cf>] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
> > [92146.548535]  [<f8645b0b>] intel_lid_notify+0x9b/0xc0 [i915]
> > [92146.548543]  [<c15610d3>] notifier_call_chain+0x43/0x60
> > [92146.548550]  [<c105d1e1>] __blocking_notifier_call_chain+0x41/0x80
> > [92146.548556]  [<c105d23f>] blocking_notifier_call_chain+0x1f/0x30
> > [92146.548563]  [<c131a684>] acpi_lid_send_state+0x78/0xa4
> > [92146.548569]  [<c131aa9e>] acpi_button_notify+0x3b/0xf1
> > [92146.548577]  [<c12df56a>] ? acpi_os_execute+0x17/0x19
> > [92146.548582]  [<c12e591a>] ? acpi_ec_sync_query+0xa5/0xbc
> > [92146.548589]  [<c12e2b82>] acpi_device_notify+0x16/0x18
> > [92146.548595]  [<c12f4904>] acpi_ev_notify_dispatch+0x38/0x4f
> > [92146.548600]  [<c12df0e8>] acpi_os_execute_deferred+0x20/0x2b
> > [92146.548607]  [<c1051208>] process_one_work+0x128/0x3f0
> > [92146.548613]  [<c1564f73>] ? common_interrupt+0x33/0x38
> > [92146.548618]  [<c104f8c0>] ? wake_up_worker+0x30/0x30
> > [92146.548624]  [<c12df0c8>] ? acpi_os_wait_events_complete+0x1e/0x1e
> > [92146.548629]  [<c10524f9>] worker_thread+0x119/0x3b0
> > [92146.548634]  [<c10523e0>] ? manage_workers+0x240/0x240
> > [92146.548640]  [<c1056e84>] kthread+0x94/0xa0
> > [92146.548647]  [<c1060000>] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0
> > [92146.548652]  [<c15649b7>] ret_from_kernel_thread+0x1b/0x28
> > [92146.548658]  [<c1056df0>] ? kthread_create_on_node+0xc0/0xc0
> >
> > so I'd like to use tristate for modeset_on_lid instead of bool.
> > -1: ingore all the lid events.
> > 0:  do not do modeset when there is a lid-open event.
> > 1:  do modeset when there is a lid-open event.
> > In this way, only device resume code will do modeset in a suspend/resume cycle.
> >
> > Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> 
> Given that this essentially requires users to manually set this module
> option to make stuff work I don't like this.
> 
> I see a few possible options:
> - plug the races between all the different parts - I've never really
> understood why acpi sends us events before the resume code has
> completed ...

This particular one may be a result of patch [2/3] in the series,
actually, because that patch makes SCI work over the whole cycle.

> If that's indeed intentional, we could delay the
> handling a bit until at least the i915 resume code completed.

I would do that for now at least if possible.  It shouldn't hurt anyway.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming
  2013-01-27 22:21     ` Rafael J. Wysocki
@ 2013-01-27 23:21       ` Daniel Vetter
  0 siblings, 0 replies; 12+ messages in thread
From: Daniel Vetter @ 2013-01-27 23:21 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Zhang Rui, linux-kernel, linux-pm, linux-acpi, intel-gfx, lenb

On Sun, Jan 27, 2013 at 11:21 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> Given that this essentially requires users to manually set this module
>> option to make stuff work I don't like this.
>>
>> I see a few possible options:
>> - plug the races between all the different parts - I've never really
>> understood why acpi sends us events before the resume code has
>> completed ...
>
> This particular one may be a result of patch [2/3] in the series,
> actually, because that patch makes SCI work over the whole cycle.
>
>> If that's indeed intentional, we could delay the
>> handling a bit until at least the i915 resume code completed.
>
> I would do that for now at least if possible.  It shouldn't hurt anyway.

Since I lack a bit clue about how the pm stuff works exactly: Is there
a ready-made helper for that kind of synchronization, where a notifier
callback can be called from a different device's resume callbacks,
which is someplace completely unrelated in the device-tree? Or any
anti-patterns to avoid?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming
  2013-01-27 15:45   ` [Intel-gfx] " Daniel Vetter
  2013-01-27 22:21     ` Rafael J. Wysocki
@ 2013-01-28  2:36     ` Zhang Rui
  2013-01-28  8:31       ` Daniel Vetter
  1 sibling, 1 reply; 12+ messages in thread
From: Zhang Rui @ 2013-01-28  2:36 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: linux-kernel, linux-pm, linux-acpi, intel-gfx, rjw, lenb

On Sun, 2013-01-27 at 16:45 +0100, Daniel Vetter wrote:
> On Sun, Jan 27, 2013 at 4:21 PM, Zhang Rui <rui.zhang@intel.com> wrote:
> > i915 driver needs to do modeset when
> > 1. system resumes from sleep
> > 2. lid is opened
> >
> > In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
> > thus it is the i915_resume code does the modeset rather than intel_lid_notify().
> >
> > In PM_SUSPEND_FREEZE state, system is still resposive to the lid events.
> > 1. When we close the lid in Freeze state, intel_lid_notify() sets modeset_on_lid.
> > 2. When we reopen the lid, intel_lid_notify() will do a modeset,
> >    before the system is resumed.
> >
> > here is the error log,
> >
> > [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x184/0x190 [i915]()
> > [92146.548076] Hardware name: VGN-Z540N
> > [92146.548078] pipe_off wait timed out
> > [92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal e1000e
> > [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: G        W    3.8.0-rc3-s0i3-v3-test+ #9
> > [92146.548175] Call Trace:
> > [92146.548189]  [<c10378e2>] warn_slowpath_common+0x72/0xa0
> > [92146.548227]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
> > [92146.548263]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
> > [92146.548270]  [<c10379b3>] warn_slowpath_fmt+0x33/0x40
> > [92146.548307]  [<f86398b4>] intel_wait_for_pipe_off+0x184/0x190 [i915]
> > [92146.548344]  [<f86399c2>] intel_disable_pipe+0x102/0x190 [i915]
> > [92146.548380]  [<f8639ea4>] ? intel_disable_plane+0x64/0x80 [i915]
> > [92146.548417]  [<f8639f7c>] i9xx_crtc_disable+0xbc/0x150 [i915]
> > [92146.548456]  [<f863ebee>] intel_crtc_update_dpms+0x5e/0x90 [i915]
> > [92146.548493]  [<f86437cf>] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
> > [92146.548535]  [<f8645b0b>] intel_lid_notify+0x9b/0xc0 [i915]
> > [92146.548543]  [<c15610d3>] notifier_call_chain+0x43/0x60
> > [92146.548550]  [<c105d1e1>] __blocking_notifier_call_chain+0x41/0x80
> > [92146.548556]  [<c105d23f>] blocking_notifier_call_chain+0x1f/0x30
> > [92146.548563]  [<c131a684>] acpi_lid_send_state+0x78/0xa4
> > [92146.548569]  [<c131aa9e>] acpi_button_notify+0x3b/0xf1
> > [92146.548577]  [<c12df56a>] ? acpi_os_execute+0x17/0x19
> > [92146.548582]  [<c12e591a>] ? acpi_ec_sync_query+0xa5/0xbc
> > [92146.548589]  [<c12e2b82>] acpi_device_notify+0x16/0x18
> > [92146.548595]  [<c12f4904>] acpi_ev_notify_dispatch+0x38/0x4f
> > [92146.548600]  [<c12df0e8>] acpi_os_execute_deferred+0x20/0x2b
> > [92146.548607]  [<c1051208>] process_one_work+0x128/0x3f0
> > [92146.548613]  [<c1564f73>] ? common_interrupt+0x33/0x38
> > [92146.548618]  [<c104f8c0>] ? wake_up_worker+0x30/0x30
> > [92146.548624]  [<c12df0c8>] ? acpi_os_wait_events_complete+0x1e/0x1e
> > [92146.548629]  [<c10524f9>] worker_thread+0x119/0x3b0
> > [92146.548634]  [<c10523e0>] ? manage_workers+0x240/0x240
> > [92146.548640]  [<c1056e84>] kthread+0x94/0xa0
> > [92146.548647]  [<c1060000>] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0
> > [92146.548652]  [<c15649b7>] ret_from_kernel_thread+0x1b/0x28
> > [92146.548658]  [<c1056df0>] ? kthread_create_on_node+0xc0/0xc0
> >
> > so I'd like to use tristate for modeset_on_lid instead of bool.
> > -1: ingore all the lid events.
> > 0:  do not do modeset when there is a lid-open event.
> > 1:  do modeset when there is a lid-open event.
> > In this way, only device resume code will do modeset in a suspend/resume cycle.
> >
> > Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> 
> Given that this essentially requires users to manually set this module
> option to make stuff work I don't like this.
> 
sorry, I do not understand.
this patch just disables modeset_on_lid during suspend.

> I see a few possible options:
> - plug the races between all the different parts - I've never really
> understood why acpi sends us events before the resume code has
> completed ... If that's indeed intentional, we could delay the
> handling a bit until at least the i915 resume code completed.

IMO, the real question is that, during a suspend/resume cycle, if we
need to take care of the lid open event or not.
To me, the answer is no, because when resuming from STR, i915 is not
aware of such an event, and the i915 resume code works well, right?
so I do not think it is a problem to ignore the lid event for another
lightweight suspend state, which is introduced in Patch 1/3 in this
series.

> - Judging from the diff context you're not on the latest 3.8-rc
> codebase - we've applied a few fixes to this lid hack recently. Please
> retest on a kernel with
> 
the patch is based on 3.8.0-rc3, which already includes the commit
below.
And yes, the problem still exists.

thanks,
rui
> commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Fri Nov 23 18:16:34 2012 +0100
> 
>     drm/i915: force restore on lid open
> 
> - This lid hack is only required since a few moronic BIOS
> implementations touch the display hw state behind our backs. On
> platforms with OpRegion support this shouldn't be the case any longer
> (which means pretty much everything shipped in the last few years), so
> we could conditionalize this hack on that (e.g. check out the existing
> dev_priv->opregion.header check in the i915_resume function in
> i915_drv.c in drm-next).
> 
> Yours, Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c   |    4 ++--
> >  drivers/gpu/drm/i915/i915_drv.h   |    2 +-
> >  drivers/gpu/drm/i915/intel_lvds.c |    2 ++
> >  3 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > index 1172658..d7613cb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -492,8 +492,8 @@ static int i915_drm_freeze(struct drm_device *dev)
> >
> >         intel_opregion_fini(dev);
> >
> > -       /* Modeset on resume, not lid events */
> > -       dev_priv->modeset_on_lid = 0;
> > +       /* Modeset on resume, ignore lid events */
> > +       dev_priv->modeset_on_lid = -1;
> >
> >         console_lock();
> >         intel_fbdev_set_suspend(dev, 1);
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index ed30595..3fec498 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -748,7 +748,7 @@ typedef struct drm_i915_private {
> >         unsigned long quirks;
> >
> >         /* Register state */
> > -       bool modeset_on_lid;
> > +       int modeset_on_lid;     /* -1: invalid, 0: no modeset, 1: do modeset */
> >
> >         struct {
> >                 /** Bridge to intel-gtt-ko */
> > diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
> > index 17aee74..4ddae6d 100644
> > --- a/drivers/gpu/drm/i915/intel_lvds.c
> > +++ b/drivers/gpu/drm/i915/intel_lvds.c
> > @@ -512,6 +512,8 @@ static int intel_lid_notify(struct notifier_block *nb, unsigned long val,
> >         if (dev->switch_power_state != DRM_SWITCH_POWER_ON)
> >                 return NOTIFY_OK;
> >
> > +       if (dev_priv->modeset_on_lid == -1)
> > +               return NOTIFY_OK;
> >         /*
> >          * check and update the status of LVDS connector after receiving
> >          * the LID nofication event.
> > --
> > 1.7.9.5
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> 
> 



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming
  2013-01-28  2:36     ` Zhang Rui
@ 2013-01-28  8:31       ` Daniel Vetter
  2013-01-28 10:06         ` Zhang Rui
  0 siblings, 1 reply; 12+ messages in thread
From: Daniel Vetter @ 2013-01-28  8:31 UTC (permalink / raw)
  To: Zhang Rui; +Cc: linux-kernel, linux-pm, linux-acpi, intel-gfx, rjw, lenb

On Mon, Jan 28, 2013 at 3:36 AM, Zhang Rui <rui.zhang@intel.com> wrote:
>> Given that this essentially requires users to manually set this module
>> option to make stuff work I don't like this.
>>
> sorry, I do not understand.
> this patch just disables modeset_on_lid during suspend.

Pardon me, the misunderstanding is on my side - I've mixed up
dev_priv->modeset_on_lid with the corresponding module option.

Is my understanding correct that only with the new SCI pm state this
can happen, since that still allows acpi events to be processed (and
so our lid_notifier being called?

>> I see a few possible options:
>> - plug the races between all the different parts - I've never really
>> understood why acpi sends us events before the resume code has
>> completed ... If that's indeed intentional, we could delay the
>> handling a bit until at least the i915 resume code completed.
>
> IMO, the real question is that, during a suspend/resume cycle, if we
> need to take care of the lid open event or not.
> To me, the answer is no, because when resuming from STR, i915 is not
> aware of such an event, and the i915 resume code works well, right?
> so I do not think it is a problem to ignore the lid event for another
> lightweight suspend state, which is introduced in Patch 1/3 in this
> series.
>
>> - Judging from the diff context you're not on the latest 3.8-rc
>> codebase - we've applied a few fixes to this lid hack recently. Please
>> retest on a kernel with
>>
> the patch is based on 3.8.0-rc3, which already includes the commit
> below.
> And yes, the problem still exists.

Ok, I think I see the issue now. But I suspect that we need some
additional locking to make this solid, since currently
dev_priv->modeset_on_lid updates can race with our lid notifier
handler. Let me think about this a bit more.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming
  2013-01-28  8:31       ` Daniel Vetter
@ 2013-01-28 10:06         ` Zhang Rui
  2013-01-29 10:10           ` Daniel Vetter
  0 siblings, 1 reply; 12+ messages in thread
From: Zhang Rui @ 2013-01-28 10:06 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: linux-kernel, linux-pm, linux-acpi, intel-gfx, rjw, lenb

On Mon, 2013-01-28 at 09:31 +0100, Daniel Vetter wrote:
> On Mon, Jan 28, 2013 at 3:36 AM, Zhang Rui <rui.zhang@intel.com> wrote:
> >> Given that this essentially requires users to manually set this module
> >> option to make stuff work I don't like this.
> >>
> > sorry, I do not understand.
> > this patch just disables modeset_on_lid during suspend.
> 
> Pardon me, the misunderstanding is on my side - I've mixed up
> dev_priv->modeset_on_lid with the corresponding module option.
> 
> Is my understanding correct that only with the new SCI pm state this
> can happen, since that still allows acpi events to be processed (and
> so our lid_notifier being called?
> 
yep.

> >> I see a few possible options:
> >> - plug the races between all the different parts - I've never really
> >> understood why acpi sends us events before the resume code has
> >> completed ... If that's indeed intentional, we could delay the
> >> handling a bit until at least the i915 resume code completed.
> >
> > IMO, the real question is that, during a suspend/resume cycle, if we
> > need to take care of the lid open event or not.
> > To me, the answer is no, because when resuming from STR, i915 is not
> > aware of such an event, and the i915 resume code works well, right?
> > so I do not think it is a problem to ignore the lid event for another
> > lightweight suspend state, which is introduced in Patch 1/3 in this
> > series.
> >
> >> - Judging from the diff context you're not on the latest 3.8-rc
> >> codebase - we've applied a few fixes to this lid hack recently. Please
> >> retest on a kernel with
> >>
> > the patch is based on 3.8.0-rc3, which already includes the commit
> > below.
> > And yes, the problem still exists.
> 
> Ok, I think I see the issue now. But I suspect that we need some
> additional locking to make this solid, since currently
> dev_priv->modeset_on_lid updates can race with our lid notifier
> handler. Let me think about this a bit more.

hmm,
with this patch, intel_lid_notify() will return immediately if
modeset_on_lid is set to -1. So the only problem in my mind is that we
got a lid open event during i915_suspend().

Say,
lid is opened -> i915_lid_notify() is invoked (modeset_on_lid is 1 at
this time) -> i915_suspend() set modeset_on_lid to -1, just before
intel_modeset_setup_hw_state() being invoked in i915_lid_notify() ->
intel_modeset_setup_hw_state() breaks the system.

but my first question would be is this (lid open on suspend) possible in
real world?
If the answer is yes, then my second question is that, this problem
exists for STR as well because SCI is still valid at this time when
suspending to memory, have we seen such issues for STR before?

Anyway, if the current code does not break STR, this patch should be
enough for the new suspend state.
what do you think?

thanks,
rui


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE
  2013-01-27 15:20 [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE Zhang Rui
  2013-01-27 15:20 ` [RFC PATCH 2/3] ACPI: enable ACPI SCI during suspend Zhang Rui
  2013-01-27 15:21 ` [RFC PATCH 3/3] i915: ignore lid open event when resuming Zhang Rui
@ 2013-01-29  2:05 ` Andreas Mohr
  2 siblings, 0 replies; 12+ messages in thread
From: Andreas Mohr @ 2013-01-29  2:05 UTC (permalink / raw)
  To: Zhang Rui; +Cc: linux-kernel, linux-pm, linux-acpi, intel-gfx, rjw, lenb

Hi,

first, thanks a lot for advancing PM infrastructure!

>  #define PM_SUSPEND_ON		((__force suspend_state_t) 0)
> -#define PM_SUSPEND_STANDBY	((__force suspend_state_t) 1)
> +#define PM_SUSPEND_FREEZE	((__force suspend_state_t) 1)
> +#define PM_SUSPEND_STANDBY	((__force suspend_state_t) 2)
>  #define PM_SUSPEND_MEM		((__force suspend_state_t) 3)
> +#define PM_SUSPEND_MIN		PM_SUSPEND_FREEZE
>  #define PM_SUSPEND_MAX		((__force suspend_state_t) 4)

I'll just pretend to be hopeful that you managed to hunt down all
relevant code sites (possibly even splattered around drivers?)
which may have made illegally hard-coded assumptions
about the number of PM_SUSPEND state "enum"s ;)
(e.g. comparisons - such as "==", "<=" etc. - come into mind)


Review of your patch was all fine, nothing to object about.

Thanks,

Andreas Mohr

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming
  2013-01-28 10:06         ` Zhang Rui
@ 2013-01-29 10:10           ` Daniel Vetter
  2013-02-04  6:26             ` Zhang Rui
  0 siblings, 1 reply; 12+ messages in thread
From: Daniel Vetter @ 2013-01-29 10:10 UTC (permalink / raw)
  To: Zhang Rui
  Cc: Daniel Vetter, linux-kernel, linux-pm, linux-acpi, intel-gfx, rjw, lenb

On Mon, Jan 28, 2013 at 06:06:38PM +0800, Zhang Rui wrote:
> On Mon, 2013-01-28 at 09:31 +0100, Daniel Vetter wrote:
> > On Mon, Jan 28, 2013 at 3:36 AM, Zhang Rui <rui.zhang@intel.com> wrote:
> > >> Given that this essentially requires users to manually set this module
> > >> option to make stuff work I don't like this.
> > >>
> > > sorry, I do not understand.
> > > this patch just disables modeset_on_lid during suspend.
> > 
> > Pardon me, the misunderstanding is on my side - I've mixed up
> > dev_priv->modeset_on_lid with the corresponding module option.
> > 
> > Is my understanding correct that only with the new SCI pm state this
> > can happen, since that still allows acpi events to be processed (and
> > so our lid_notifier being called?
> > 
> yep.
> 
> > >> I see a few possible options:
> > >> - plug the races between all the different parts - I've never really
> > >> understood why acpi sends us events before the resume code has
> > >> completed ... If that's indeed intentional, we could delay the
> > >> handling a bit until at least the i915 resume code completed.
> > >
> > > IMO, the real question is that, during a suspend/resume cycle, if we
> > > need to take care of the lid open event or not.
> > > To me, the answer is no, because when resuming from STR, i915 is not
> > > aware of such an event, and the i915 resume code works well, right?
> > > so I do not think it is a problem to ignore the lid event for another
> > > lightweight suspend state, which is introduced in Patch 1/3 in this
> > > series.
> > >
> > >> - Judging from the diff context you're not on the latest 3.8-rc
> > >> codebase - we've applied a few fixes to this lid hack recently. Please
> > >> retest on a kernel with
> > >>
> > > the patch is based on 3.8.0-rc3, which already includes the commit
> > > below.
> > > And yes, the problem still exists.
> > 
> > Ok, I think I see the issue now. But I suspect that we need some
> > additional locking to make this solid, since currently
> > dev_priv->modeset_on_lid updates can race with our lid notifier
> > handler. Let me think about this a bit more.
> 
> hmm,
> with this patch, intel_lid_notify() will return immediately if
> modeset_on_lid is set to -1. So the only problem in my mind is that we
> got a lid open event during i915_suspend().
> 
> Say,
> lid is opened -> i915_lid_notify() is invoked (modeset_on_lid is 1 at
> this time) -> i915_suspend() set modeset_on_lid to -1, just before
> intel_modeset_setup_hw_state() being invoked in i915_lid_notify() ->
> intel_modeset_setup_hw_state() breaks the system.
> 
> but my first question would be is this (lid open on suspend) possible in
> real world?
> If the answer is yes, then my second question is that, this problem
> exists for STR as well because SCI is still valid at this time when
> suspending to memory, have we seen such issues for STR before?
> 
> Anyway, if the current code does not break STR, this patch should be
> enough for the new suspend state.
> what do you think?

I think I have two wishlist changes for your patch ;-)

- Convert dev_priv->modeset_on_lid to an enum, so that we have descriptive
  names instead of magic numbers.

- I think we can close all races by adding a new lid_notifier mutex (I
  prefer a new lock instead of overloading an existing one with). If we
  hold that in the suspend/resume paths just for changing modeset_on_lid
  and also for the entire lid notifier callback (i.e. grab the lock before
  first looking at modest_on_lid, only drop it once the modeset fixup has
  been completed at the end of the function) we should be race-free in all
  cases.

  Also, I think we should move the modeset_on_lid updates in the
  suspend/resume paths to the very beginning/end.

Can you pls update your patch with these changes? Or do you see an
additional race we need to plug somewhere?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [Intel-gfx] [RFC PATCH 3/3] i915: ignore lid open event when resuming
  2013-01-29 10:10           ` Daniel Vetter
@ 2013-02-04  6:26             ` Zhang Rui
  0 siblings, 0 replies; 12+ messages in thread
From: Zhang Rui @ 2013-02-04  6:26 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: linux-kernel, linux-pm, linux-acpi, intel-gfx, rjw, lenb

On Tue, 2013-01-29 at 11:10 +0100, Daniel Vetter wrote:
> On Mon, Jan 28, 2013 at 06:06:38PM +0800, Zhang Rui wrote:
> > On Mon, 2013-01-28 at 09:31 +0100, Daniel Vetter wrote:
> > > On Mon, Jan 28, 2013 at 3:36 AM, Zhang Rui <rui.zhang@intel.com> wrote:
> > > >> Given that this essentially requires users to manually set this module
> > > >> option to make stuff work I don't like this.
> > > >>
> > > > sorry, I do not understand.
> > > > this patch just disables modeset_on_lid during suspend.
> > > 
> > > Pardon me, the misunderstanding is on my side - I've mixed up
> > > dev_priv->modeset_on_lid with the corresponding module option.
> > > 
> > > Is my understanding correct that only with the new SCI pm state this
> > > can happen, since that still allows acpi events to be processed (and
> > > so our lid_notifier being called?
> > > 
> > yep.
> > 
> > > >> I see a few possible options:
> > > >> - plug the races between all the different parts - I've never really
> > > >> understood why acpi sends us events before the resume code has
> > > >> completed ... If that's indeed intentional, we could delay the
> > > >> handling a bit until at least the i915 resume code completed.
> > > >
> > > > IMO, the real question is that, during a suspend/resume cycle, if we
> > > > need to take care of the lid open event or not.
> > > > To me, the answer is no, because when resuming from STR, i915 is not
> > > > aware of such an event, and the i915 resume code works well, right?
> > > > so I do not think it is a problem to ignore the lid event for another
> > > > lightweight suspend state, which is introduced in Patch 1/3 in this
> > > > series.
> > > >
> > > >> - Judging from the diff context you're not on the latest 3.8-rc
> > > >> codebase - we've applied a few fixes to this lid hack recently. Please
> > > >> retest on a kernel with
> > > >>
> > > > the patch is based on 3.8.0-rc3, which already includes the commit
> > > > below.
> > > > And yes, the problem still exists.
> > > 
> > > Ok, I think I see the issue now. But I suspect that we need some
> > > additional locking to make this solid, since currently
> > > dev_priv->modeset_on_lid updates can race with our lid notifier
> > > handler. Let me think about this a bit more.
> > 
> > hmm,
> > with this patch, intel_lid_notify() will return immediately if
> > modeset_on_lid is set to -1. So the only problem in my mind is that we
> > got a lid open event during i915_suspend().
> > 
> > Say,
> > lid is opened -> i915_lid_notify() is invoked (modeset_on_lid is 1 at
> > this time) -> i915_suspend() set modeset_on_lid to -1, just before
> > intel_modeset_setup_hw_state() being invoked in i915_lid_notify() ->
> > intel_modeset_setup_hw_state() breaks the system.
> > 
> > but my first question would be is this (lid open on suspend) possible in
> > real world?
> > If the answer is yes, then my second question is that, this problem
> > exists for STR as well because SCI is still valid at this time when
> > suspending to memory, have we seen such issues for STR before?
> > 
> > Anyway, if the current code does not break STR, this patch should be
> > enough for the new suspend state.
> > what do you think?
> 
> I think I have two wishlist changes for your patch ;-)
> 
> - Convert dev_priv->modeset_on_lid to an enum, so that we have descriptive
>   names instead of magic numbers.
> 
sure, will update in next version.

> - I think we can close all races by adding a new lid_notifier mutex (I
>   prefer a new lock instead of overloading an existing one with). If we
>   hold that in the suspend/resume paths just for changing modeset_on_lid
>   and also for the entire lid notifier callback (i.e. grab the lock before
>   first looking at modest_on_lid, only drop it once the modeset fixup has
>   been completed at the end of the function) we should be race-free in all
>   cases.
> 
>   Also, I think we should move the modeset_on_lid updates in the
>   suspend/resume paths to the very beginning/end.
> 
> Can you pls update your patch with these changes? Or do you see an
> additional race we need to plug somewhere?
> 
yep. will send out V2 soon.
thanks for your comments.

-rui


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2013-02-04  6:26 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-27 15:20 [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE Zhang Rui
2013-01-27 15:20 ` [RFC PATCH 2/3] ACPI: enable ACPI SCI during suspend Zhang Rui
2013-01-27 15:21 ` [RFC PATCH 3/3] i915: ignore lid open event when resuming Zhang Rui
2013-01-27 15:45   ` [Intel-gfx] " Daniel Vetter
2013-01-27 22:21     ` Rafael J. Wysocki
2013-01-27 23:21       ` Daniel Vetter
2013-01-28  2:36     ` Zhang Rui
2013-01-28  8:31       ` Daniel Vetter
2013-01-28 10:06         ` Zhang Rui
2013-01-29 10:10           ` Daniel Vetter
2013-02-04  6:26             ` Zhang Rui
2013-01-29  2:05 ` [RFC PATCH 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE Andreas Mohr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).