This is being worked upstream and tracked here:
https://bugs.freedesktop.org/show_bug.cgi?id=89611

For reference to others, here is the text of the freedesktop bug submission. Please follow-up there. This bug will be closed when the freedesktop bug is closed.

I've observed that from at least 3.17.1 through 3.19.1 (I don't know if
this worked previously), the MinnowBoard MAX (Firmware 0.77 or 0.78) will
suspend and resume successfully once, but fail to suspend after the
initial resume.

$ echo mem > /sys/power/state
<suspends successfully>
<press and release power button>
<system resumes>

The following Intel DRM PM warning appears on the console:
[   67.772124] ------------[ cut here ]------------
[   67.784552] WARNING: CPU: 0 PID: 570 at
drivers/gpu/drm/i915/intel_pm.c:5043
intel_gen6_powersave_work+0xf6a/0x11d0()
[   67.803814] WARN_ON(pctx_addr != dev_priv->mm.stolen_base +
dev_priv->vlv_pctx->stolen->start)
[   67.813591] Modules linked in: iptable_nat nf_nat_ipv4 nf_nat i2c_i801
dw_dmac dw_dmac_core i2c_designware_platform i2c_designware_core
spi_pxa2xx_platform
[   67.844750] CPU: 0 PID: 570 Comm: kworker/0:1 Tainted: G        W
3.19.1 #2
[   67.860960] Hardware name: Circuitco MinnowBoard MAX B3
PLATFORM/MinnowBoard MAX, BIOS MNW2MAX1.X64.0078.R01.1503091142 03/09/2015
[   67.882352] Workqueue: events intel_gen6_powersave_work
[   67.896476]  ffffffff81c0b548 ffff88003a933cf8 ffffffff818b52b3
ffff88003940ea30
[   67.913321]  ffff88003a933d48 ffff88003a933d38 ffffffff8104ef85
ffff88003a933d28
[   67.928496]  ffff88003abf0000 ffff880038c00000 ffff88003abf8828
ffff88003abf88c0
[   67.942521] Call Trace:
[   67.950068]  [<ffffffff818b52b3>] dump_stack+0x45/0x57
[   67.960676]  [<ffffffff8104ef85>] warn_slowpath_common+0x85/0xc0
[   67.971700]  [<ffffffff8104f001>] warn_slowpath_fmt+0x41/0x50
[   67.981949]  [<ffffffff81427d4a>] intel_gen6_powersave_work+0xf6a/0x11d0
[   67.992920]  [<ffffffff8112c953>] ? vmstat_shepherd+0x123/0x140
[   68.002707]  [<ffffffff81065cb0>] process_one_work+0x150/0x400
[   68.012393]  [<ffffffff810662bb>] worker_thread+0x6b/0x480
[   68.021690]  [<ffffffff81066250>] ? rescuer_thread+0x2f0/0x2f0
[   68.031389]  [<ffffffff8106ac06>] kthread+0xd6/0xf0
[   68.040002]  [<ffffffff8106ab30>] ? kthread_create_on_node+0x180/0x180
[   68.050507]  [<ffffffff818bd56c>] ret_from_fork+0x7c/0xb0
[   68.059745]  [<ffffffff8106ab30>] ? kthread_create_on_node+0x180/0x180
[   68.070263] ---[ end trace be1bc8f8605e963c ]---


$ echo mem > /sys/power/state
[   98.340941] PM: Syncing filesystems ... done.
[   98.357282] PM: Preparing system for mem sleep
[   98.376033] Freezing user space processes ... (elapsed 0.001 seconds)
done.
[   98.395983] Freezing remaining freezable tasks ... (elapsed 0.001
seconds) done.
[   98.416075] PM: Entering mem sleep
[   98.430013] Suspending console(s) (use no_console_suspend to debug)


The system does not suspend (display does not enter standby), and is
non-responsive to USB keyboard and serial console input.

If I blacklist the i915 module, the system will suspend and resume successfully repeatedly (I tried four in a row).

I have attached a dmesg log following the first successful resume with drm.debug=14. I saw no drm output after issuing the second suspend command.