> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Alex Williamson
> Sent: Monday, November 6, 2017 10:39 AM
> To: Zhang, Tina
> Cc: Tian, Kevin ; Daniel Vetter
> ;
> intel-gfx@lists.freedesktop.org; joonas.lahti...@linux.intel
On 11/5/2017 9:25 PM, Michal Wajdeczko wrote:
On Sun, 05 Nov 2017 14:39:42 +0100, Sagar Arun Kamble
wrote:
Current wait timeout of 10us is very tight as seen on SKL/KBL randomly
for pm_rpm@basic-pci-d3-state. Increase it to 50us.
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Mich
On 11/01/2017 07:51 PM, Jani Nikula wrote:
drm_add_edid_modes() now fills in the ELD automatically, so the calls to
drm_edid_to_eld() are redundant. Remove them.
All the other places are obvious, but nv50 has detached
drm_edid_to_eld() from the drm_add_edid_modes() call.
For the bridge drive
On Mon, 6 Nov 2017 10:19:17 +0800
Tina Zhang wrote:
> Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user query and get
> a plane and its related information. So far, two types of buffers are
> supported: buffers based on dma-buf and buffers based on region.
>
> This ioctl can be invoked
== Series Details ==
Series: drm/i915/gvt: Dma-buf support for GVT-g
URL : https://patchwork.freedesktop.org/series/33222/
State : failure
== Summary ==
Series 33222 revision 1 was fully merged or fully failed: no git log
___
Intel-gfx mailing list
The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in
windows. The float format in each component is 1:5:10 MSb-sign:exponent:
fraction.
This patch is to introduce the format to drm, so that the windows guest's
framebuffer in this kind of format can be recognized and used by linu
This patch introduces a guest's framebuffer sharing mechanism based on
dma-buf subsystem. With this sharing mechanism, guest's framebuffer can
be shared between guest VM and host.
v16:
- add x_hot and y_hot. (Gerd)
- add flag validation for VFIO_DEVICE_GET_GFX_DMABUF. (Alex)
- rebase 4.14.0-rc6.
Windows guest driver needs vbt in opregion, to configure the setting
for display. Without opregion support, the display registers won't
be set and this blocks display model to get the correct information
of the guest display plane.
This patch is to provide a virtual opregion for guest. Current
imp
Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user query and get
a plane and its related information. So far, two types of buffers are
supported: buffers based on dma-buf and buffers based on region.
This ioctl can be invoked with:
1) either DMABUF or REGION flag. Vendor driver returns a pl
The RGB 64-bit 16:16:16:16 float pixel format is needed by windows 10
guest VM. This patch is to add this pixel format support to gvt device
model. Without this patch, some Apps, e.g. "DXGIGammaVM.exe", will crash
and make guest screen black.
Signed-off-by: Tina Zhang
---
drivers/gpu/drm/i915/gv
v15->v16:
1) add cursor hotspot fields in struct vfio_device_gfx_plane_info. (Gerd)
2) clean up some typos and add comments for VFIO_DEVICE_QUERY_GFX_PLANE. (Alex)
3) seperate the GEM Proxy part to another patch-set. (Joonas and Chris)
https://lists.freedesktop.org/archives/intel-gvt-dev/2017-N
This patch is to introduce the framebuffer decoder which can decode guest
OS's framebuffer information, including primary, cursor and sprite plane.
v16:
rebase to 4.14.0-rc6.
v14:
- refine pixel format table. (Zhenyu)
v9:
- move drm format change to a separate patch. (Xiaoguang)
v8:
- fix a bu
== Series Details ==
Series: series starting with [CI,1/8] drm/i915: Define an engine class enum for
the uABI
URL : https://patchwork.freedesktop.org/series/33211/
State : warning
== Summary ==
Test kms_chv_cursor_fail:
Subgroup pipe-B-128x128-bottom-edge:
pass -
On Sun, 05 Nov 2017 14:39:42 +0100, Sagar Arun Kamble
wrote:
Current wait timeout of 10us is very tight as seen on SKL/KBL randomly
for pm_rpm@basic-pci-d3-state. Increase it to 50us.
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Michał Winiarski
Cc: Michel Thierry
Cc: Michal Waj
== Series Details ==
Series: drm/i915: Read ilk FDI PLL frequency once during initialisation
URL : https://patchwork.freedesktop.org/series/33210/
State : success
== Summary ==
Test kms_setmode:
Subgroup basic:
pass -> FAIL (shard-hsw) fdo#99912
fdo#99912 h
== Series Details ==
Series: series starting with [CI,1/8] drm/i915: Define an engine class enum for
the uABI
URL : https://patchwork.freedesktop.org/series/33211/
State : success
== Summary ==
Series 33211v1 series starting with [CI,1/8] drm/i915: Define an engine class
enum for the uABI
ht
== Series Details ==
Series: drm/i915: Read ilk FDI PLL frequency once during initialisation
URL : https://patchwork.freedesktop.org/series/33210/
State : success
== Summary ==
Series 33210v1 drm/i915: Read ilk FDI PLL frequency once during initialisation
https://patchwork.freedesktop.org/api/
== Series Details ==
Series: series starting with [1/5] drm/i915/guc: Separate GuC doorbell destroy
function into doorbell unit and GuC task
URL : https://patchwork.freedesktop.org/series/33209/
State : warning
== Summary ==
Series 33209v1 series starting with [1/5] drm/i915/guc: Separate GuC
In the next few patches, we will want to both copy out of the context
image and write a valid image into a new context. To be completely safe,
we should then couple in our domain tracking to ensure that we don't
have any issues with stale data remaining in unwanted cachelines.
Historically, we omi
intel_modeset_gem_init() now only sets up the legacy overlay, so let's
remove the function and call the setup directly during driver load. This
should help us find a better point in the initialisation sequence for it
later.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Mi
GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().
Signed-off-by: Chris Wilson
Cc
In the next few patches, we will have a hard requirement that we emit a
context-switch to the perma-pinned i915->kernel_context (so that we can
save the HW state using that context-switch). As the first context
itself may be classed as a kernel context, we want to be explicit in our
comparison. For
Let userspace know if they can trust that new contexts are created using
HW default values; and avoid inheriting state from existing contexts.
Note: I intend to squash this into the bugfix once we agree on the uabi.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Cc: Tvrtko U
As we now record the default HW state and so only emit the "golden"
renderstate once to prepare the HW, there is no advantage in keeping the
renderstate batch around as it will never be used again.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h
Take a copy of the HW state after a reset upon module loading by
executing a context switch from a blank context to the kernel context,
thus saving the default hw state over the blank context image.
We can then use the default hw state to initialise any future context,
ensuring that each starts wit
From: Tvrtko Ursulin
We want to be able to report back to userspace details about an engine's
class, and in return for userspace to be able to request actions
regarding certain classes of engines. To isolate the uABI from any
variations between hw generations, we define an abstract class for the
During intel_atomic_check(), we do not take the intel_runtime_pm_get()
wakeref and so should do the atomic modeset precalculations without
referring to the HW. However, on Ironlake we see
<7>[ 23.487557] [drm:intel_atomic_check [i915]] [CONNECTOR:47:VGA-1] checking
for sink bpp constrains
<7>[
Current wait timeout of 10us is very tight as seen on SKL/KBL randomly
for pm_rpm@basic-pci-d3-state. Increase it to 50us.
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Michał Winiarski
Cc: Michel Thierry
Cc: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
---
drivers/gpu/
Before GT device suspend, i915 should release GuC client doorbells by
stopping doorbell controller snooping and doorbell deallocation through
GuC. They need to be acquired again on resume. This will also resolve
the driver unload issue with GuC, where doorbell deallocation was being
done post GEM s
Releasing GuC doorbell involves stopping the doorbell unit snooping and
executing doorbell deallocation flow in GuC firmware. When GuC is in sane
state, both steps will be necessary to release doorbell.
If GuC is hung (possibly leading to i915 reset), only doorbell unit
snooping is to be stopped. d
Also revert ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions")
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
drivers/gpu/drm/i915/i915_params.h | 4 ++--
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/dri
Prior to i915 reset, we need to deactivate all client doorbells
as they will need to be reacquired again post reset. We should
not execute GuC doorbell deallocation flow as GuC might be in
bad state (possibly reason for i915 reset).
Signed-off-by: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Michał Wi
== Series Details ==
Series: drm/i915: Assert vma->flags are updated correctly during binding (rev3)
URL : https://patchwork.freedesktop.org/series/33199/
State : failure
== Summary ==
Series 33199v3 drm/i915: Assert vma->flags are updated correctly during binding
https://patchwork.freedesktop
On 5 November 2017 at 12:45, Chris Wilson wrote:
> As we bind, and unbind on error, we want to be sure that the vma->flags
> are updated to reflect the binding state so that on the next invocation
> all is well.
>
> v2: Take two.
> v3: Take three; vma-misplaced is checking map-and-fenceable so kee
As we bind, and unbind on error, we want to be sure that the vma->flags
are updated to reflect the binding state so that on the next invocation
all is well.
v2: Take two.
v3: Take three; vma-misplaced is checking map-and-fenceable so keep it
last!
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
== Series Details ==
Series: drm/i915: Assert vma->flags are updated correctly during binding (rev2)
URL : https://patchwork.freedesktop.org/series/33199/
State : failure
== Summary ==
Series 33199v2 drm/i915: Assert vma->flags are updated correctly during binding
https://patchwork.freedesktop
As we bind, and unbind on error, we want to be sure that the vma->flags
are updated to reflect the binding state so that on the next invocation
all is well.
v2: Take two.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_vma.c | 8 ++--
1 file
== Series Details ==
Series: drm/i915: Assert vma->flags are updated correctly during binding
URL : https://patchwork.freedesktop.org/series/33199/
State : failure
== Summary ==
Series 33199v1 drm/i915: Assert vma->flags are updated correctly during binding
https://patchwork.freedesktop.org/ap
As we bind, and unbind on error, we want to be sure that the vma->flags
are updated to reflect the binding state so that on the next invocation
all is well.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_vma.c | 2 ++
1 file changed, 2 insertions
39 matches
Mail list logo
