Re: [Intel-gfx] [Intel-wired-lan] [PATCH v2 1/1] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails

2017-06-04 Thread Neftin, Sasha
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]

[Intel-gfx] i915 memory allocation failure..

2017-06-04 Thread Linus Torvalds
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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix GVT-g PVINFO version compatibility check

2017-06-04 Thread Patchwork
== 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

[Intel-gfx] [PATCH] drm/i915: Fix GVT-g PVINFO version compatibility check

2017-06-04 Thread Zhenyu Wang
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

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf

2017-06-04 Thread Chen, Xiaoguang
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

Re: [Intel-gfx] [PATCH v8 03/20] drm/i915: Modify error handler for per engine hang recovery

2017-06-04 Thread Chris Wilson
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

Re: [Intel-gfx] [PATCH v8 03/20] drm/i915: Modify error handler for per engine hang recovery

2017-06-04 Thread Chris Wilson
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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Enable cold boot for GLK DSI

2017-06-04 Thread Patchwork
== 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/

[Intel-gfx] [PATCH] drm/i915/glk: Enable cold boot for GLK DSI

2017-06-04 Thread Madhav Chauhan
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