[Intel-gfx] [PATCH] drm/i915/glk: Enable cold boot for GLK DSI
As per BSEPC, if device ready bit is '0' in enable IO sequence
then its a cold boot/reset scenario eg: S3/S4 resume. In these
conditions we need to program certain registers and prepare port
from the middle of DSI enable sequence otherwise feature like S3/S4
doesn't work.
V2: Do not assume that on enable when power has not been lost,
all the registers contain the correct information already.
Program DSI registers for normal boot scenario from
glk_dsi_device_ready() (Jani N).
Signed-off-by: Madhav Chauhan
---
drivers/gpu/drm/i915/intel_dsi.c | 82 +---
1 file changed, 51 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index fc0ef49..5582859 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -346,12 +346,17 @@ static bool intel_dsi_compute_config(struct intel_encoder
*encoder,
return true;
}
-static void glk_dsi_device_ready(struct intel_encoder *encoder)
+static void intel_dsi_prepare(struct intel_encoder *intel_encoder,
+ struct intel_crtc_state *pipe_config);
+
+static void glk_dsi_device_ready(struct intel_encoder *encoder,
+struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base);
enum port port;
u32 tmp, val;
+ bool cold_boot = false;
/* Set the MIPI mode
* If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
@@ -370,7 +375,10 @@ static void glk_dsi_device_ready(struct intel_encoder
*encoder)
/* Program LP Wake */
for_each_dsi_port(port, intel_dsi->ports) {
tmp = I915_READ(MIPI_CTRL(port));
- tmp |= GLK_LP_WAKE;
+ if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY))
+ tmp &= ~GLK_LP_WAKE;
+ else
+ tmp |= GLK_LP_WAKE;
I915_WRITE(MIPI_CTRL(port), tmp);
}
@@ -382,6 +390,15 @@ static void glk_dsi_device_ready(struct intel_encoder
*encoder)
DRM_ERROR("MIPIO port is powergated\n");
}
+ /* Check if cold boot scenario */
+ for_each_dsi_port(port, intel_dsi->ports) {
+ cold_boot |= !(I915_READ(MIPI_DEVICE_READY(port)) &
+ DEVICE_READY);
+ }
+
+ if (cold_boot)
+ intel_dsi_prepare(encoder, pipe_config);
+
/* Wait for MIPI PHY status bit to set */
for_each_dsi_port(port, intel_dsi->ports) {
if (intel_wait_for_register(dev_priv,
@@ -402,34 +419,34 @@ static void glk_dsi_device_ready(struct intel_encoder
*encoder)
val |= DEVICE_READY;
I915_WRITE(MIPI_DEVICE_READY(port), val);
usleep_range(10, 15);
- }
-
- /* Enter ULPS */
- val = I915_READ(MIPI_DEVICE_READY(port));
- val &= ~ULPS_STATE_MASK;
- val |= (ULPS_STATE_ENTER | DEVICE_READY);
- I915_WRITE(MIPI_DEVICE_READY(port), val);
+ } else {
+ /* Enter ULPS */
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val &= ~ULPS_STATE_MASK;
+ val |= (ULPS_STATE_ENTER | DEVICE_READY);
+ I915_WRITE(MIPI_DEVICE_READY(port), val);
- /* Wait for ULPS active */
- if (intel_wait_for_register(dev_priv,
+ /* Wait for ULPS active */
+ if (intel_wait_for_register(dev_priv,
MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0, 20))
- DRM_ERROR("ULPS not active\n");
+ DRM_ERROR("ULPS not active\n");
- /* Exit ULPS */
- val = I915_READ(MIPI_DEVICE_READY(port));
- val &= ~ULPS_STATE_MASK;
- val |= (ULPS_STATE_EXIT | DEVICE_READY);
- I915_WRITE(MIPI_DEVICE_READY(port), val);
+ /* Exit ULPS */
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val &= ~ULPS_STATE_MASK;
+ val |= (ULPS_STATE_EXIT | DEVICE_READY);
+ I915_WRITE(MIPI_DEVICE_READY(port), val);
- /* Enter Normal Mode */
- val = I915_READ(MIPI_DEVICE_READY(port));
- val &= ~ULPS_STATE_MASK;
- val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
- I915_WRITE(MIPI_DEVICE_READY(port), val);
+ /* Enter Normal Mode */
+ val = I915_READ(MIPI_DEVICE_READY(port));
+ val &= ~ULPS_STATE_MASK;
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Enable cold boot for GLK DSI
== Series Details == Series: drm/i915/glk: Enable cold boot for GLK DSI URL : https://patchwork.freedesktop.org/series/25253/ State : success == Summary == Series 25253v1 drm/i915/glk: Enable cold boot for GLK DSI https://patchwork.freedesktop.org/api/1.0/series/25253/revisions/1/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:449s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:434s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:582s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:516s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:485s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:478s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:433s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:419s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:416s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:503s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:461s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:463s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:567s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:459s fi-skl-6700hqtotal:278 pass:228 dwarn:1 dfail:0 fail:27 skip:22 time:399s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:464s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:504s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:438s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time:404s d919ad0d077110d2d48a4b7503ddc02c3864667d drm-tip: 2017y-06m-02d-21h-49m-57s UTC integration manifest 56e8ae7 drm/i915/glk: Enable cold boot for GLK DSI == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4871/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 03/20] drm/i915: Modify error handler for per engine hang recovery
Quoting Chris Wilson (2017-06-02 21:16:42)
> I think you want to do something like:
>
> if (intel_has_engine_reset()) {
> for_each_engine_mask() {
> if (test_and_set_bit(I915_RESET_ENGINE + engine->id))
> continue;
>
> if (i915_reset_engine() == 0)
> engine_mask &= ~engine->mask;
>
> clear_bit(I915_RESET_ENGINE + engine->id);
> wake_up_bit(I915_RESET_ENGINE + engine->id);
> }
> }
>
> if (!engine_mask)
> goto out;
>
> if (test_and_set_bit(I915_RESET_BACKOFF))
> goto out;
>
> for_each_engine() {
> wait_on_bit(I915_RESET_ENGINE + engine->id);
> set_bit(I915_RESET_ENGINE);
> }
This needs to be in a loop for that sweet layer of paranoia.
while (test_and_set_bit(I915_RESET_ENGINE + engine->id))
wait_on_bit(I915_RESET_ENGINE + engine->id);
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 03/20] drm/i915: Modify error handler for per engine hang recovery
And whilst I'm here, we need to extend I915_PARAM_HAS_GPU_RESET to indicate having per-engine resets for the complimentary set of igt. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf
Hi, >-Original Message- >From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On >Behalf Of Gerd Hoffmann >Sent: Friday, June 02, 2017 11:24 PM >To: Alex Williamson ; Chen, Xiaoguang > >Cc: Tian, Kevin ; intel-gfx@lists.freedesktop.org; linux- >ker...@vger.kernel.org; zhen...@linux.intel.com; ch...@chris-wilson.co.uk; Lv, >Zhiyuan ; intel-gvt-...@lists.freedesktop.org; Wang, Zhi >A >Subject: Re: [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can >get >the dma-buf > > Hi, > >> > When i915's dma-buf's release() callback is called it will try to >> > free the gem object associated with the dma-buf if its ref count is >> > 0. But in our case the ref count is 1 so no free callback is called >> > so we can not release allocations there. > >Why the ref count is one? The gem object is created by us while creating the dma-buf(the ref count of the gem object is initialized to 1). Later when user import the dma-buf the ref count of the gem object associate with the dma-buf will increased. When user finished using the dma-buf it will decrease the ref count. But the ref count of the gem object will become 1 when all the user finished using the dma-buf because we create the gem object(the test also showing this result). Typically user only export a dma-buf(no gem object yet) then when user import the dma-buf then a gem object will be created. But in our case we do not implement the dma-buf from scratch but calling the i915_gem_prime_export() where a gem object is an input parameter. Chenxg >Who holds a reference and why? >Maybe it should be the other way around, i.e. the dmabuf holds a reference on >the vgpu instance backing it, i.e. you can't delete the vgpu while dma-bufs >exist? > >> We cannot simply say that the user isn't allowed to release them in >> that order. > >Yep, not going to fly. Can happen even unintentionally because we can pass >around dmabufs to other processes. Example: qemu passes dmabuf to spice- >client, then qemu crashes. mgmt fd is closed before dmabuf fd then. The >kernel >must be able to handle that. > >cheers, > Gerd >___ >intel-gvt-dev mailing list >intel-gvt-...@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix GVT-g PVINFO version compatibility check
Current it's strictly checked if PVINFO version matches 1.0
for GVT-g i915 guest which doesn't help for compatibility at
all and forces GVT-g host can't extend PVINFO easily with version
bump for real compatibility check.
This fixes that to check minimal required PVINFO version instead
and currently minimal 1.0 is required.
Cc: Chuanxiao Dong
Cc: Joonas Lahtinen
Cc: sta...@vger.kernel.org # 4.10+
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/i915_pvinfo.h | 3 ++-
drivers/gpu/drm/i915/i915_vgpu.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h
b/drivers/gpu/drm/i915/i915_pvinfo.h
index c0cb2974caac..96434707857e 100644
--- a/drivers/gpu/drm/i915/i915_pvinfo.h
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -37,7 +37,8 @@
#define VGT_VERSION_MINOR 0
#define INTEL_VGT_IF_VERSION_ENCODE(major, minor) ((major) << 16 | (minor))
-#define INTEL_VGT_IF_VERSION \
+/* minimal required PVINFO version */
+#define INTEL_VGT_IF_VERSION_REQUIRED \
INTEL_VGT_IF_VERSION_ENCODE(VGT_VERSION_MAJOR, VGT_VERSION_MINOR)
/*
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 4ab8a973b61f..5798572e6db3 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -72,7 +72,7 @@ void i915_check_vgpu(struct drm_i915_private *dev_priv)
version = INTEL_VGT_IF_VERSION_ENCODE(
__raw_i915_read16(dev_priv, vgtif_reg(version_major)),
__raw_i915_read16(dev_priv, vgtif_reg(version_minor)));
- if (version != INTEL_VGT_IF_VERSION) {
+ if (version < INTEL_VGT_IF_VERSION_REQUIRED) {
DRM_INFO("VGT interface version mismatch!\n");
return;
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix GVT-g PVINFO version compatibility check
== Series Details == Series: drm/i915: Fix GVT-g PVINFO version compatibility check URL : https://patchwork.freedesktop.org/series/25275/ State : warning == Summary == Series 25275v1 drm/i915: Fix GVT-g PVINFO version compatibility check https://patchwork.freedesktop.org/api/1.0/series/25275/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> FAIL (fi-snb-2600) fdo#100215 Test drv_module_reload: Subgroup basic-reload-final: pass -> DMESG-WARN (fi-skl-6770hq) fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time:438s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time:587s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time:516s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time:494s fi-byt-n2820 total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:499s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:436s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time:421s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:496s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time:461s fi-kbl-7500u total:278 pass:255 dwarn:5 dfail:0 fail:0 skip:18 time:477s fi-kbl-7560u total:278 pass:263 dwarn:5 dfail:0 fail:0 skip:10 time:563s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time:456s fi-skl-6700hqtotal:278 pass:228 dwarn:1 dfail:0 fail:27 skip:22 time:401s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time:466s fi-skl-6770hqtotal:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time:501s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time:434s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time:535s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time:411s d919ad0d077110d2d48a4b7503ddc02c3864667d drm-tip: 2017y-06m-02d-21h-49m-57s UTC integration manifest 0c9adb6 drm/i915: Fix GVT-g PVINFO version compatibility check == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4872/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] i915 memory allocation failure..
So there's something wrong with the memory allocation changes since 4.11, which seem to be mostly credited to Chris Wilson. In particular, I got this earlier today: Xorg: page allocation failure: order:0, mode:0x14210d2(GFP_HIGHUSER|__GFP_NORETRY|__GFP_RECLAIMABLE), nodemask=(null) and then soon afterwards in the log I see chrome[13102]: segfault at 968 ip 7f472a7fda83 sp 7fffab9a6ef0 error 4 in libX11.so.6.3.0[7f472a7d1000+138000] gnome-session-f[13115]: segfault at 0 ip 7f7e765ab4b9 sp 7ffca5990470 error 4 in libgtk-3.so.0.2200.15[7f7e762cc000+6f9000] which I assume is related to broken error handling. So there's at least two bugs here: (a) order-0 memory allocation failure is generally a sign of something bad. We clearly give up *much* too easily. (b) using __GFP_NORETRY and wanting the memory failure, but then not using __GFP_NOWARN is just stupid. Now, (b) initially made me go "I'll just add that __GFP_NOWARN myself". Because it's true - if you intentionally tell the VM subsystem that you'd rather get a failed allocation than try a bit harder, then you obviously shouldn't get the warning either. I think the VM people have talked about just considering NORETRY to imply NOWARN. However, the fact that this actually caused problems in downstream user space, and the fact that this happened with an order-0 allocation made me re-consider. That allocation clearly *is* important, and returning NULL may "work" from a kernel standpoint, but it sure as hell didn't work in the bigger picture, now did it? So the warning was actually good in this case. This may in fact be an example of why GFP_NORETRY should *not* imply NOWARN. So instead of shutting up the warning, I pass it over to the i915 people. Making that allocation fail easily wasn't such a great idea after all, was it? Maybe that NORETRY should be reconsidered, at least for important (perhaps small?) allocations? Also adding some VM people, because I think it's ridiculous that the 0-order allocation failed in the first place. Full report attached, there's tons of memory that should have been trivial to free. So I suspect GFP_NORETRY ends up being *much* too aggressive, and basically doesn't even try any trivial freeing. Maybe we want some middle ground between "retry forever" and "don't try at all". In people trying to fight the "retry forever", we seem to have gone too far in the "don't even bother, just return NULL" direction. Added a random mixture of i915 and MM people. Feel free to send this message further if you feel I missed somebody, Linus gfp-noretry Description: Binary data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails
On 5/31/2017 18:50, Jani Nikula wrote:
From: Chris Wilson
An error during suspend (e100e_pm_suspend),
[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER: 0011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[ 430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[ 430.955458] PM: Device :00:19.0 failed to suspend async: error -2
[ 430.955581] PM: Some devices failed to suspend, or early wake event detected
[ 430.957709] ACPI : EC: event unblocked
lead to complete failure:
[ 432.585002] [ cut here ]
[ 432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478
__free_irq+0x9f/0x280
[ 432.585015] Trying to free already-free IRQ 20
[ 432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal
intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci
i915 mmc_core e1000e ptp pps_core prime_numbers
[ 432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U
4.10.0-rc8-CI-Patchwork_3870+ #1
[ 432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 )
07/02/2012
[ 432.585050] Workqueue: events_unbound async_run_entry_fn
[ 432.585051] Call Trace:
[ 432.585058] dump_stack+0x67/0x92
[ 432.585062] __warn+0xc6/0xe0
[ 432.585065] warn_slowpath_fmt+0x4a/0x50
[ 432.585070] ? _raw_spin_lock_irqsave+0x49/0x60
[ 432.585072] __free_irq+0x9f/0x280
[ 432.585075] free_irq+0x34/0x80
[ 432.585089] e1000_free_irq+0x65/0x70 [e1000e]
[ 432.585098] e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[ 432.585106] e1000e_pm_suspend+0x21/0x30 [e1000e]
[ 432.585113] pci_pm_suspend+0x71/0x140
[ 432.585118] dpm_run_callback+0x6f/0x330
[ 432.585122] ? pci_pm_freeze+0xe0/0xe0
[ 432.585125] __device_suspend+0xea/0x330
[ 432.585128] async_suspend+0x1a/0x90
[ 432.585132] async_run_entry_fn+0x34/0x160
[ 432.585137] process_one_work+0x1f4/0x6d0
[ 432.585140] ? process_one_work+0x16e/0x6d0
[ 432.585143] worker_thread+0x49/0x4a0
[ 432.585145] kthread+0x107/0x140
[ 432.585148] ? process_one_work+0x6d0/0x6d0
[ 432.585150] ? kthread_create_on_node+0x40/0x40
[ 432.585154] ret_from_fork+0x2e/0x40
[ 432.585156] ---[ end trace 6712df7f8c4b9124 ]---
The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.
Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Cc: Tvrtko Ursulin
Cc: Jeff Kirsher
Cc: Dave Ertman
Cc: Bruce Allan
Cc: intel-wired-...@lists.osuosl.org
Cc: net...@vger.kernel.org
Signed-off-by: Chris Wilson
[Jani: bikeshed repainted]
Signed-off-by: Jani Nikula
---
drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index b3679728caac..5cad688be609 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6630,12 +6630,17 @@ static int e1000e_pm_thaw(struct device *dev)
static int e1000e_pm_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
+ int rc;
e1000e_flush_lpic(pdev);
e1000e_pm_freeze(dev);
- return __e1000_shutdown(pdev, false);
+ rc = __e1000_shutdown(pdev, false);
+ if (rc)
+ e1000e_pm_thaw(dev);
+
+ return rc;
}
static int e1000e_pm_resume(struct device *dev)
Good. Let's pick up this patch.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 memory allocation failure..
On Sun 04-06-17 21:26:06, Linus Torvalds wrote: [...] > Also adding some VM people, because I think it's ridiculous that the > 0-order allocation failed in the first place. Full report attached, > there's tons of memory that should have been trivial to free. Node 0 DMA32 free:64228kB min:12788kB low:15984kB high:19180kB active_anon:1222056kB inactive_anon:257972kB active_file:38748kB inactive_file:1065188kB unevictable:0kB writepending:916280kB present:3173852kB managed:3104264kB mlocked:0kB slab_reclaimable:39816kB slab_unreclaimable:6812kB kernel_stack:416kB pagetables:5472kB bounce:0kB free_pcp:860kB local_pcp:12kB free_cma:0kB lowmem_reserve[]: 0 0 12894 12894 Node 0 Normal free:54304kB min:54728kB low:68408kB high:82088kB active_anon:3323732kB inactive_anon:819528kB active_file:4876676kB inactive_file:3096768kB unevictable:448kB writepending:812kB present:13484032kB managed:13206364kB mlocked:448kB slab_reclaimable:702912kB slab_unreclaimable:89800kB kernel_stack:13248kB pagetables:70472kB bounce:0kB free_pcp:4808kB local_pcp:628kB free_cma:0kB lowmem_reserve[]: 0 0 0 0 Yeah, there is a lot of reclaimable memory. And I suspect that the direct reclaim has freed some of it (well, actually SWAP_CLUSTER_MAX as we asked for). > So I suspect GFP_NORETRY ends up being *much* too aggressive, and > basically doesn't even try any trivial freeing. Well, __GFP_NORETRY has been failing after a _single_ reclaim attempt failure (__alloc_pages_direct_reclaim). Nothing has changed recently in that regards. So if there is a heavy sustained memory pressure which keeps consuming reclaimed pages while the reclaimer has any chance to consume them then __GFP_NORETRY fails. > Maybe we want some middle ground between "retry forever" and "don't > try at all". In people trying to fight the "retry forever", we seem to > have gone too far in the "don't even bother, just return NULL" > direction. Yes, I am trying to convert GFP_REPEAT into something like that for quite some time. See http://lkml.kernel.org/r/20170307154843.32516-1-mho...@kernel.org -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
