Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

On Tue, 2017-07-25 at 10:01 +0200, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same.

[Intel-gfx] [PATCH v13 1/7] drm/i915/gvt: Add framebuffer decoder support

Framebuffer decoder returns guest framebuffer information. Guest framebuffer includes primary, cursor and sprite plane. Signed-off-by: Xiaoguang Chen Signed-off-by: Tina Zhang --- drivers/gpu/drm/i915/gvt/Makefile | 3 +-

[Intel-gfx] [PATCH v13 3/7] drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format support

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: Xiaoguang Chen

[Intel-gfx] [PATCH v13 4/7] drm/i915/gvt: Add opregion support

Windows guest UPT driver can use operegion to configure the setting for display. Without the opregion support, the display registers won't be set and this blocks display model to get the correct information of the guest display plane. Signed-off-by: Bing Niu Signed-off-by:

[Intel-gfx] [PATCH v13 2/7] drm: Introduce RGB 64-bit 16:16:16:16 float format

The RGB 64-bit 16:16:16:16 float pixel format is needed by windows guest VM. This patch is to introduce the format to drm. v1: Suggested by Ville to submit this patch to dri-devel. Signed-off-by: Xiaoguang Chen Signed-off-by: Tina Zhang ---

[Intel-gfx] [PATCH v13 0/7] drm/i915/gvt: Dma-buf support for GVT-g

v12->v13: 1) add comments to GEM proxy. (Chris) 2) don't ban GEM proxy in i915_gem_sw_finish_ioctl. (Chris) 3) check GEM proxy bar after finishing i915_gem_object_wait. (Chris) 4) remove GEM proxy bar in i915_gem_madvise_ioctl. v11->v12: 1) add drm_format_mod back. (Gerd and Zhenyu) 2) add

Re: [Intel-gfx] [PATCH 15/20] drm/i915: Don't touch fence->error when resetting an innocent request

Quoting Michel Thierry (2017-07-24 20:32:21) > On 7/24/2017 6:32 AM, Chris Wilson wrote: > > Quoting Chris Wilson (2017-07-21 13:32:33) > >> If the request has been completed before the reset took effect, we don't > >> need to mark it up as being a victim. Touching fence->error after the > >>

Re: [Intel-gfx] [PATCH 1/8] drm/omap: Simplify the rotation-on-crtc hack

Op 25-07-17 om 10:01 schreef Daniel Vetter: > I want/need to rework the core property handling, and this hack is > getting in the way. But since it's a non-standard propety only used by > legacy userspace we know that this will only every be called from > ioctl code. And never on some other

Re: [Intel-gfx] [PATCH v7 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

Hi Andrzej, Thanks for the feedback. Can you tell me if that following changes are correct? Cheers, - Lionel On 25/07/17 10:06, Datczuk, Andrzej wrote: Hi Lionel, What about the corrected whitelist I sent you before? Without allowing those registers the patch for MDAPI is basically

Re: [Intel-gfx] [PATCH v7 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

I think you looked only at the changes prepared previously by Matthew and just ported by me. I made a change on top of it in a third patch to alight the whitelist with MDAPI needs. The change you're looking for is "Subject: [PATCH 3/3] drm/i915: extended oa reg addresses whitelist". To make it

[Intel-gfx] [PATCH] drm: Don't update property values for atomic drivers

Atomic drivers only use the property value store for immutable (i.e. can't be set by userspace, but the kernel can still adjust it) properties. The only tricky part is the removal of the update in drm_atomic_helper_update_legacy_modeset_state(). This was added in commit

Re: [Intel-gfx] [PATCH v7 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

Hi Lionel, What about the corrected whitelist I sent you before? Without allowing those registers the patch for MDAPI is basically useless. FYI The whitelist from the patches I sent you contained merged ranges for gen7-9 platforms. Regards, Andrzej -Original Message- From: Landwerlin,

Re: [Intel-gfx] [PATCH v2 2/7] drm/atomic: Clean up drm_atomic_helper_async_check

On Tue, Jul 25, 2017 at 11:11 AM, Maarten Lankhorst wrote: > Op 25-07-17 om 10:23 schreef Daniel Vetter: >> On Wed, Jul 19, 2017 at 04:39:15PM +0200, Maarten Lankhorst wrote: >>> /* >>> - * Don't do an async update if there is an outstanding commit

Re: [Intel-gfx] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

On 07/25/2017 01:31 PM, Daniel Vetter wrote: It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_plane_set_property. Reviewed-by: Archit Taneja Signed-off-by: Daniel Vetter Cc: Liviu

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Dma-buf support for GVT-g

== Series Details == Series: drm/i915/gvt: Dma-buf support for GVT-g URL : https://patchwork.freedesktop.org/series/27844/ State : warning == Summary == Series 27844v1 drm/i915/gvt: Dma-buf support for GVT-g https://patchwork.freedesktop.org/api/1.0/series/27844/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH v2 2/7] drm/atomic: Clean up drm_atomic_helper_async_check

Op 25-07-17 om 11:27 schreef Daniel Vetter: > On Tue, Jul 25, 2017 at 11:11 AM, Maarten Lankhorst > wrote: >> Op 25-07-17 om 10:23 schreef Daniel Vetter: >>> On Wed, Jul 19, 2017 at 04:39:15PM +0200, Maarten Lankhorst wrote: /* - * Don't do an

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Add perf property support for context HW id

On 25/07/17 05:26, Zhenyu Wang wrote: On 2017.07.21 14:01:01 +0100, Lionel Landwerlin wrote: I think Chris' comments show this isn't actually tested. It turned out that's true...so currently Pengyuan just tried to filter by exposed vGPU ctx_hw_id with global mode in gputop. Would that be ok

Re: [Intel-gfx] [PATCH i-g-t] lib/drmtest: Decode driver flags on failure

Quoting Daniel Vetter (2017-07-25 12:37:08) > I spent too much time going wtf why does this test not run until > realizing that vgem is missing. This should help a lot for tests that > need multiple different drm drivers. > > Signed-off-by: Daniel Vetter > --- >

Re: [Intel-gfx] [PATCH v2 3/7] drm/rcar-du: Use new iterator macros, v2.

On Wed, Jul 19, 2017 at 04:39:16PM +0200, Maarten Lankhorst wrote: > for_each_obj_in_state is about to be removed, so use the correct new > iterator macros. > > Also look at new_plane_state instead of plane->state when looking up > the hw planes in use. They should be the same except when

[Intel-gfx] ✓ Fi.CI.BAT: success for acquire ctx for everyone!

== Series Details == Series: acquire ctx for everyone! URL : https://patchwork.freedesktop.org/series/27835/ State : success == Summary == Series 27835v1 acquire ctx for everyone! https://patchwork.freedesktop.org/api/1.0/series/27835/revisions/1/mbox/ Test kms_cursor_legacy:

Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

On 07/25/2017 01:31 PM, Daniel Vetter wrote: It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over

[Intel-gfx] [PATCH] drm: Handle properties in the core for atomic drivers

The reason behind the original indirection through the helper functions was to allow existing drivers to overwrite how they handle properties. For example when a vendor-specific userspace had expectations that didn't match atomic. That seemed likely, since atomic is standardizing a _lot_ more of

[Intel-gfx] [PATCH v13 7/7] drm/i915/gvt: Dmabuf support for GVT-g

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. Signed-off-by: Tina Zhang --- drivers/gpu/drm/i915/gvt/Makefile | 2 +-

Re: [Intel-gfx] [PATCH 3/8] drm: Handle properties in the core for atomic drivers

On 07/25/2017 01:31 PM, Daniel Vetter wrote: The reason behind the original indirection through the helper functions was to allow existing drivers to overwrite how they handle properties. For example when a vendor-specific userspace had expectations that didn't match atomic. That seemed

[Intel-gfx] [PATCH v13 6/7] drm/i915: Introduce GEM proxy

GEM proxy is a kind of GEM, whose backing physical memory is pinned and produced by guest VM and is used by host as read only. With GEM proxy, host is able to access guest physical memory through GEM object interface. As GEM proxy is such a special kind of GEM, a new flag I915_GEM_OBJECT_IS_PROXY

Re: [Intel-gfx] [PATCH 2/8] drm: Don't update property values for atomic drivers

Op 25-07-17 om 10:01 schreef Daniel Vetter: > Atomic drivers only use the property value store for immutable (i.e. > can't be set by userspace, but the kernel can still adjust it) > properties. The only tricky part is the removal of the update in > drm_atomic_helper_update_legacy_modeset_state().

[Intel-gfx] [PATCH v13 5/7] vfio: ABI for mdev display dma-buf operation

Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and get the plan and its related information. The dma-buf's life cycle is handled by user mode and tracked by kernel. The returned fd in struct vfio_device_query_gfx_plane can be a new fd or an old fd of a re-exported dma-buf.

Re: [Intel-gfx] [PATCH 8/8] drm: Nuke drm_atomic_legacy_backoff

Op 25-07-17 om 10:01 schreef Daniel Vetter: > Finally all users are gone! > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_atomic.c | 32 > include/drm/drm_atomic.h | 2 -- > 2 files changed, 34 deletions(-) > > diff --git

Re: [Intel-gfx] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_plane_set_property. > > Signed-off-by: Daniel Vetter > Cc: Liviu Dudau > Cc: Brian Starkey

Re: [Intel-gfx] [PATCH 4/8] drm: Nuke drm_atomic_helper_crtc_set_property

On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code because this is now handled in the core. > > Signed-off-by: Daniel Vetter > Cc: Boris Brezillon > Cc: Daniel Vetter > Cc: Jani Nikula

[Intel-gfx] ✗ Fi.CI.BAT: failure for acquire ctx for everyone! (rev3)

== Series Details == Series: acquire ctx for everyone! (rev3) URL : https://patchwork.freedesktop.org/series/27835/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK

Re: [Intel-gfx] [PATCH v2 2/7] drm/atomic: Clean up drm_atomic_helper_async_check

Op 25-07-17 om 10:23 schreef Daniel Vetter: > On Wed, Jul 19, 2017 at 04:39:15PM +0200, Maarten Lankhorst wrote: >> Instead of assigning plane to __plane, iterate over plane >> which is the same thing. Simplify the check for n_planes != 1, >> at that point we know plane != NULL as well. >> >>

Re: [Intel-gfx] [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property

Op 25-07-17 om 10:01 schreef Daniel Vetter: > It's dead code, the core handles all this directly now. This also > allows us to unexport drm_atomic_helper_connector_set_property. > > The only special case is nouveau which used one function for both > pre-nv50 legacy modeset code and post-nv50

Re: [Intel-gfx] [PATCH 1/8] drm/omap: Simplify the rotation-on-crtc hack

On Tue, Jul 25, 2017 at 10:47 AM, Maarten Lankhorst wrote: > Op 25-07-17 om 10:01 schreef Daniel Vetter: >> I want/need to rework the core property handling, and this hack is >> getting in the way. But since it's a non-standard propety only used by >> legacy

Re: [Intel-gfx] [PATCH 4/8] drm: Nuke drm_atomic_helper_crtc_set_property

On 07/25/2017 01:31 PM, Daniel Vetter wrote: It's dead code because this is now handled in the core. Reviewed-by: Archit Taneja Signed-off-by: Daniel Vetter Cc: Boris Brezillon Cc: Daniel Vetter

Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

On 07/25/2017 10:01 AM, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > v2:

Re: [Intel-gfx] [PATCH 0/4] [v2] Blobifiers (FKA GET_PLANE2)

On 07/24/2017 05:46 AM, Ben Widawsky wrote: > Second attempt (although most patches are much further along than that) and > the > blob property for modifiers. > > This small series adds the DRM blob property that allows clients to be made > aware of per plane modifiers and the formats which

[Intel-gfx] [PATCH i-g-t] lib/drmtest: Decode driver flags on failure

I spent too much time going wtf why does this test not run until realizing that vgem is missing. This should help a lot for tests that need multiple different drm drivers. Signed-off-by: Daniel Vetter --- lib/drmtest.c | 21 - 1 file changed, 20

Re: [Intel-gfx] [PATCH v2 4/7] drm/omapdrm: Fix omap_atomic_wait_for_completion

On Wed, Jul 19, 2017 at 04:39:17PM +0200, Maarten Lankhorst wrote: > Use the new iterator macro and look for crtc_state->active instead of > enable, only crtc_state->enable implies that vblanks will happen. s/enable/active/, since enable only means logically enabled (aka resources reserved). With

Re: [Intel-gfx] [PATCH v2 7/7] drm/atomic: Remove deprecated accessor macros

On Wed, Jul 19, 2017 at 04:39:20PM +0200, Maarten Lankhorst wrote: > Now that the last users have been converted, we can finally get rid of > for_each_obj_in_state, we have better macros to replace them with. > > Signed-off-by: Maarten Lankhorst > Cc: Daniel

Re: [Intel-gfx] [PATCH v2 6/7] drm/nouveau: Convert nouveau to use new iterator macros, v2.

On Wed, Jul 19, 2017 at 04:39:19PM +0200, Maarten Lankhorst wrote: > Use the new atomic iterator macros, the old ones are about to be > removed. With the new macros, it's more easy to get old and new state so > get them from the macros instead of from obj->state. > > Changes since v1: > - Don't

Re: [Intel-gfx] [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property

On Tue, Jul 25, 2017 at 11:23 AM, Maarten Lankhorst wrote: > Op 25-07-17 om 10:01 schreef Daniel Vetter: >> It's dead code, the core handles all this directly now. This also >> allows us to unexport drm_atomic_helper_connector_set_property. >> >> The only special case is

Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later

On 2017-07-25 02:15, Puthikorn Voravootivat wrote: I saw a DP 1.3 panel that advertise AUX backlight brightness control but not working properly. So it should work but not in real world. I think that is good reason enough to add this as a heuristic. Either key it on eDP 1.4 and hope that it's

[Intel-gfx] [drm-intel:for-linux-next 4/4] drivers/gpu/drm/i915/selftests/intel_hangcheck.c:845:3: error: too few arguments to function 'i915_reset'

tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: af2788925ae0b83737ee847c5b2e9f19c5bf3630 commit: af2788925ae0b83737ee847c5b2e9f19c5bf3630 [4/4] drm/i915: Squelch reset messages during selftests config: i386-randconfig-x013-201730 (attached as .config) compiler: gcc-6

[Intel-gfx] [PATCH i-g-t] igt: Move read_rc6_residency function to lib

Gem_mocs_settings and pm_rc6_residency tests are defining the same functionality to read residency from sysfs. Moving that function to lib/igt_aux and updating tests. Signed-off-by: Ewelina Musial --- lib/igt_aux.c | 8 lib/igt_aux.h |

[Intel-gfx] [PATCH i-g-t 2/3] configure.ac: Disable chamelium by default and add enable argument

Since the chamelium is not a very usual piece of hardware and requires pulling-in lots of specific dependencies, it makes sense to keep it disabled by default. An explicit --enable-chamelium argument is provided to enable it when necessary. This also leads to more predictable results than

[Intel-gfx] [PATCH i-g-t 1/3] configure.ac: Make udev a dependency for chamelium

Chamelium testing has a hard dependency on udev. This makes this dependency explicit in configure instead of failing the build when it is missing. Signed-off-by: Paul Kocialkowski --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Intel-gfx] [PATCH i-g-t 3/3] README: Add information about chamelium dependencies

This adds a list of dependencies required to build chamelium support, so that what needs to be installed to get it going is more obvious. As done previously in the file, the list is relevant for Debian and its derivatives but should provide a template for other systems as well. Signed-off-by:

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix kbuild error

Quoting Chris Wilson (2017-07-25 13:53:36) > After rebasing af2788925ae0 ("drm/i915: Squelch reset messages during > selftests"), I missed fixing up a call to i915_reset(). s/rebasing/applying patches out of order due to review timing/ > Reported-by: kbuild test robot >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/sdvo: Shut up state checker with hdmi cards on gen3

== Series Details == Series: drm/i915/sdvo: Shut up state checker with hdmi cards on gen3 URL : https://patchwork.freedesktop.org/series/27860/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK

Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

On Tue, Jul 25, 2017 at 10:01:21AM +0200, Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly

[Intel-gfx] [PATCH] drm/i915/selftests: Fix kbuild error

After rebasing af2788925ae0 ("drm/i915: Squelch reset messages during selftests"), I missed fixing up a call to i915_reset(). Reported-by: kbuild test robot Fixes: af2788925ae0 ("drm/i915: Squelch reset messages during selftests") Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Enforce that CS packets are qword aligned

Quoting Tvrtko Ursulin (2017-07-24 09:06:28) > > > On 21/07/2017 17:11, Chris Wilson wrote: > > We require the caller to ensure that the packets they wish to emit into > > the CS ring are qword aligned (i.e. have an even number of dwords). > > Double check this. > > > > Signed-off-by: Chris

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix kbuild error

== Series Details == Series: drm/i915/selftests: Fix kbuild error URL : https://patchwork.freedesktop.org/series/27856/ State : success == Summary == Series 27856v1 drm/i915/selftests: Fix kbuild error https://patchwork.freedesktop.org/api/1.0/series/27856/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix kbuild error

Quoting Chris Wilson (2017-07-25 13:53:36) > After rebasing af2788925ae0 ("drm/i915: Squelch reset messages during > selftests"), I missed fixing up a call to i915_reset(). > > Reported-by: kbuild test robot > Fixes: af2788925ae0 ("drm/i915: Squelch reset messages during

Re: [Intel-gfx] [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed

On Tue, 2017-07-25 at 10:16 +0200, Daniel Vetter wrote: > On Tue, Jul 25, 2017 at 10:58:55AM +0300, Paul Kocialkowski wrote: > > On Tue, 2017-07-25 at 09:34 +0200, Daniel Vetter wrote: > > > On Tue, Jul 25, 2017 at 9:25 AM, Paul Kocialkowski > > > wrote: > > > >

Re: [Intel-gfx] [PATCH i-g-t] lib/drmtest: Decode driver flags on failure

On Tue, Jul 25, 2017 at 12:49:11PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-25 12:37:08) > > I spent too much time going wtf why does this test not run until > > realizing that vgem is missing. This should help a lot for tests that > > need multiple different drm drivers. > > >

Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

Hi Daniel, Thank you for the patch. On Tuesday 25 Jul 2017 10:01:21 Daniel Vetter wrote: > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 >

Re: [Intel-gfx] [RFC v3] drm/hdcp: drm enum property for CP State

On Mon, Jul 24, 2017 at 2:12 PM, Ramalingam C wrote: > DRM connector property is created to represent the content protection > state of the connector and to configure the same. > > Content protection states defined: > DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED

Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later

On Tue, Jul 25, 2017 at 03:41:46PM +0300, David Weinehall wrote: > On 2017-07-25 02:15, Puthikorn Voravootivat wrote: > > I saw a DP 1.3 panel that advertise AUX backlight brightness control > > but not working properly. So it should work but not in real world. > > I think that is good reason

[Intel-gfx] [PATCH] drm/i915/sdvo: Shut up state checker with hdmi cards on gen3

The hdmi bits simply don't exist, so nerf them. I think audio doesn't work on gen3 at all, and for the limited color range we should probably use the colorimetry sdvo paramater instead of the bit in the port. But fixing sdvo isn't my goal, I just want to get the backtrace out of the way, and this

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix kbuild error

On Tue, Jul 25, 2017 at 01:53:36PM +0100, Chris Wilson wrote: > After rebasing af2788925ae0 ("drm/i915: Squelch reset messages during > selftests"), I missed fixing up a call to i915_reset(). > > Reported-by: kbuild test robot > Fixes: af2788925ae0 ("drm/i915: Squelch reset

Re: [Intel-gfx] [PATCH i-g-t 3/3] README: Add information about chamelium dependencies

R-b'd and pushed, thanks! On Tue, 2017-07-25 at 15:48 +0300, Paul Kocialkowski wrote: > This adds a list of dependencies required to build chamelium support, > so that what needs to be installed to get it going is more obvious. > > As done previously in the file, the list is relevant for Debian

Re: [Intel-gfx] [PATCH i-g-t 1/3] configure.ac: Make udev a dependency for chamelium

R-b'd and pushed, thanks! On Tue, 2017-07-25 at 15:48 +0300, Paul Kocialkowski wrote: > Chamelium testing has a hard dependency on udev. This makes this > dependency explicit in configure instead of failing the build when it > is missing. > > Signed-off-by: Paul Kocialkowski

Re: [Intel-gfx] [PATCH v7 3/3] drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface

On 25/07/17 12:30, Datczuk, Andrzej wrote: I think you looked only at the changes prepared previously by Matthew and just ported by me. I made a change on top of it in a third patch to alight the whitelist with MDAPI needs. The change you're looking for is "Subject: [PATCH 3/3] drm/i915:

Re: [Intel-gfx] [PATCH i-g-t v3 0/5] Add Y-tiling support into IGTs

Em Ter, 2017-07-18 às 22:52 +0530, Praveen Paneri escreveu: > This series adds Y-tiled buffer creation support into IGT libraries > and > goes on to use this capability to add support into FBC tests to use > Y-tiled buffers. Everything reviewed & merged. Thanks for the patches. Patch 5 contained

[Intel-gfx] [PATCH i-g-t 1/2] igt: Move read_rc6_residency function to lib

Gem_mocs_settings and pm_rc6_residency tests are defining the same functionality to read residency from sysfs. Moving that function to lib/igt_aux and updating tests. Signed-off-by: Ewelina Musial --- lib/igt_aux.c | 8 lib/igt_aux.h |

[Intel-gfx] [PATCH i-g-t 2/2] tests/drv_suspend: Add subtests to check that forcewake is kept after resume

In some cases we observed that forcewake isn't kept after resume and checking RC6 residency is a simple way to verify that. If forcewake is kept after resume residency should be constant. Cc: Lukasz Fiedorowicz Cc: Radoslaw Szwichtenberg

Re: [Intel-gfx] [PATCH i-g-t v3 0/5] Add Y-tiling support into IGTs

On Tuesday 25 July 2017 08:48 PM, Paulo Zanoni wrote: Em Ter, 2017-07-18 às 22:52 +0530, Praveen Paneri escreveu: This series adds Y-tiled buffer creation support into IGT libraries and goes on to use this capability to add support into FBC tests to use Y-tiled buffers. Everything reviewed

[Intel-gfx] [PATCH v4 RESEND 3/4] drm/i915/edp: Be less aggressive about changing link config on eDP

This set of changes has some history to them. There were several attempts to add what was called "fast link training" to i915, which actually wasn't fast link training as per the DP spec. These changes were 5fa836a9d859 ("drm/i915: DP link training optimization") 4e96c97742f4 ("drm/i915: eDP

[Intel-gfx] [PATCH v4 RESEND 4/4] drm/i915/edp: Allow alternate fixed mode for eDP if available.

Some fixed resolution panels actually support more than one mode, with the only thing different being the refresh rate. Having this alternate mode available to us is desirable, because it allows us to test PSR on panels whose setup time at the preferred mode is too long. With this patch we allow

[Intel-gfx] [PATCH v4 RESEND 0/4] Kernel PSR Fix-ups

These patches, along with an upcoming series for IGT, enable our PSR IGT tests to run reliably once again on HSW, BDW, and SKL. The first change enables us to run the PSR tests on some RVP platforms whose panels have too slow of a setup time when running in their preferred mode. The second fixes

[Intel-gfx] [PATCH v4 RESEND 2/4] drm/i915/psr: Account for sink CRC raciness on some panels

According to the eDP spec, when the count field in TEST_SINK_MISC increments then the six bytes of sink CRC information in the DPCD should be valid. Unfortunately, this doesn't seem to be the case on some panels, and as a result we get some incorrect and inconsistent values from the sink CRC DPCD

[Intel-gfx] [PATCH v4 RESEND 1/4] drm/i915/psr: Clean-up intel_enable_source_psr1()

On SKL+ there is a bit in SRD_CTL that software is not supposed to modify, but we currently clobber that bit when we enable PSR. In order to preserve the value of that bit, go ahead and read SRD_CTL and do a field-wise setting of the various bits that we need to initialize before writing the

Re: [Intel-gfx] [PATCH i-g-t 2/3] configure.ac: Disable chamelium by default and add enable argument

I like this patch, however there's a mistake in it: On Tue, 2017-07-25 at 15:48 +0300, Paul Kocialkowski wrote: > Since the chamelium is not a very usual piece of hardware and > requires > pulling-in lots of specific dependencies, it makes sense to keep it > disabled by default. > > An explicit

[Intel-gfx] ✗ Fi.CI.BAT: failure for Kernel PSR Fix-ups

== Series Details == Series: Kernel PSR Fix-ups URL : https://patchwork.freedesktop.org/series/27879/ State : failure == Summary == Series 27879v1 Kernel PSR Fix-ups https://patchwork.freedesktop.org/api/1.0/series/27879/revisions/1/mbox/ Test core_auth: Subgroup basic-auth:

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/drv_suspend: Add subtests to check that forcewake is kept after resume

Quoting Ewelina Musial (2017-07-25 16:26:09) > In some cases we observed that forcewake isn't kept after > resume and checking RC6 residency is a simple way to verify that. > If forcewake is kept after resume residency should be constant. > > Cc: Lukasz Fiedorowicz

Re: [Intel-gfx] [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed

On Tue, Jul 25, 2017 at 03:18:04PM +0300, Paul Kocialkowski wrote: > On Tue, 2017-07-25 at 10:16 +0200, Daniel Vetter wrote: > > On Tue, Jul 25, 2017 at 10:58:55AM +0300, Paul Kocialkowski wrote: > > > On Tue, 2017-07-25 at 09:34 +0200, Daniel Vetter wrote: > > > > On Tue, Jul 25, 2017 at 9:25 AM,

Re: [Intel-gfx] [PATCH v4 RESEND 0/4] Kernel PSR Fix-ups

On Tue, Jul 25, 2017 at 09:48:07AM -0700, Jim Bride wrote: > These patches, along with an upcoming series for IGT, enable our > PSR IGT tests to run reliably once again on HSW, BDW, and SKL. > The first change enables us to run the PSR tests on some RVP platforms > whose panels have too slow of a

Re: [Intel-gfx] [PATCH v5] drm/i915: Fix FBC cfb stride programming for non X-tiled FB

Em Qua, 2017-07-19 às 00:27 +0530, Praveen Paneri escreveu: > When FBC is enabled for linear, legacy Y-tiled and Yf-tiled > surfaces on gen9, the cfb stride must be programmed by SW as > > cfb_stride = ceiling[(at least plane width in pixels)/ >  (32 * compression limit factor)]

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence

Em Seg, 2017-07-17 às 15:05 -0700, Manasi Navare escreveu: > The condition for setting the Loadgen Select bit of > PORT_TX_DW4 register during DDI Vswing Sequence should be > Bit rate <=6 GHz whereas the existing code checks only > Bit Rate < 6GHz. This patch fixes this condition. > While at it

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence

Thanks for the review ! Manasi Em Seg, 2017-07-17 às 15:05 -0700, Manasi Navare escreveu: > The condition for setting the Loadgen Select bit of > PORT_TX_DW4 register during DDI Vswing Sequence should be Bit rate <=6 > GHz whereas the existing code checks only Bit Rate < 6GHz. This patch >

[Intel-gfx] [PATCH] drm/i915: Handle msr read failure gracefully

When reading the i915_energy_uJ debugfs file, it tries to fetch MSR_RAPL_POWER_UNIT, which might not be available, like in a vm environment, causing the exception shown below. We can easily prevent it by doing a rdmsrl_safe read instead, which will handle the exception, allowing us to abort the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle msr read failure gracefully

== Series Details == Series: drm/i915: Handle msr read failure gracefully URL : https://patchwork.freedesktop.org/series/27884/ State : success == Summary == Series 27884v1 drm/i915: Handle msr read failure gracefully https://patchwork.freedesktop.org/api/1.0/series/27884/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed

On Tue, 2017-07-25 at 09:34 +0200, Daniel Vetter wrote: > On Tue, Jul 25, 2017 at 9:25 AM, Paul Kocialkowski > wrote: > > On Tue, 2017-07-25 at 08:53 +0200, Daniel Vetter wrote: > > > On Mon, Jul 24, 2017 at 05:54:46PM +0300, Paul Kocialkowski wrote: > > > >

[Intel-gfx] [PATCH 0/8] acquire ctx for everyone!

Hi all, This is the final bits of my cleanup work to get rid of the implicit acquire context for atomic drivers. This handles the property stuff by essentially just ripping it all out, after 20+ drivers I don't see any need for a driver to overwrite anything here. Except omapdrm, and that is

[Intel-gfx] [PATCH 3/8] drm: Handle properties in the core for atomic drivers

The reason behind the original indirection through the helper functions was to allow existing drivers to overwrite how they handle properties. For example when a vendor-specific userspace had expectations that didn't match atomic. That seemed likely, since atomic is standardizing a _lot_ more of

[Intel-gfx] [PATCH 1/8] drm/omap: Simplify the rotation-on-crtc hack

I want/need to rework the core property handling, and this hack is getting in the way. But since it's a non-standard propety only used by legacy userspace we know that this will only every be called from ioctl code. And never on some other free-standing state struct, where this old hack wouldn't

[Intel-gfx] [PATCH 2/8] drm: Don't update property values for atomic drivers

Atomic drivers only use the property value store for immutable (i.e. can't be set by userspace, but the kernel can still adjust it) properties. The only tricky part is the removal of the update in drm_atomic_helper_update_legacy_modeset_state(). This was added in commit

[Intel-gfx] [PATCH 4/8] drm: Nuke drm_atomic_helper_crtc_set_property

It's dead code because this is now handled in the core. Signed-off-by: Daniel Vetter Cc: Boris Brezillon Cc: Daniel Vetter Cc: Jani Nikula Cc: Sean Paul

[Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

It's dead code, the core handles all this directly now. The only special case is nouveau and tda988x which used one function for both legacy modeset code and -nv50 atomic world instead of 2 vtables. But amounts to exactly the same. v2: Rebase over the panel/brideg refactorings in stm/ltdc.

[Intel-gfx] [PATCH 8/8] drm: Nuke drm_atomic_legacy_backoff

Finally all users are gone! Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_atomic.c | 32 include/drm/drm_atomic.h | 2 -- 2 files changed, 34 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c

[Intel-gfx] [PATCH 5/8] drm: Nuke drm_atomic_helper_plane_set_property

It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_plane_set_property. Signed-off-by: Daniel Vetter Cc: Liviu Dudau Cc: Brian Starkey Cc: Mali DP Maintainers

[Intel-gfx] [PATCH 6/8] drm: Nuke drm_atomic_helper_connector_set_property

It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_connector_set_property. The only special case is nouveau which used one function for both pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 vtables. But amounts to exactly

Re: [Intel-gfx] [PATCH 7/8] drm: Nuke drm_atomic_helper_connector_dpms

Le 25/07/2017 10:01, Daniel Vetter a écrit : > It's dead code, the core handles all this directly now. > > The only special case is nouveau and tda988x which used one function > for both legacy modeset code and -nv50 atomic world instead of 2 > vtables. But amounts to exactly the same. > > v2:

Re: [Intel-gfx] [PATCH 1/2] drm/edid: Add helper to detect whether EDID changed

On Tue, Jul 25, 2017 at 10:58:55AM +0300, Paul Kocialkowski wrote: > On Tue, 2017-07-25 at 09:34 +0200, Daniel Vetter wrote: > > On Tue, Jul 25, 2017 at 9:25 AM, Paul Kocialkowski > > wrote: > > > On Tue, 2017-07-25 at 08:53 +0200, Daniel Vetter wrote: > > > >

Re: [Intel-gfx] [PATCH v2 1/7] drm/atomic: Use new iterator macros in drm_atomic_helper_wait_for_flip_done, again.

On Wed, Jul 19, 2017 at 04:39:14PM +0200, Maarten Lankhorst wrote: > for_each_obj_in_state is about to be removed, so use the correct new > iterator macro. > > I renamed the variable to 'unused', but forgot to convert > drm_atomic_helper_wait_for_flip_done to the new iterator macro, > so make it

Re: [Intel-gfx] [PATCH v2 2/7] drm/atomic: Clean up drm_atomic_helper_async_check

On Wed, Jul 19, 2017 at 04:39:15PM +0200, Maarten Lankhorst wrote: > Instead of assigning plane to __plane, iterate over plane > which is the same thing. Simplify the check for n_planes != 1, > at that point we know plane != NULL as well. > > Rename obj_state to new_obj_state, and get rid of the

[Intel-gfx] [PATCH 04/21] drm/i915: introduce page_size_mask to dev_info

In preparation for huge gtt pages expose a page_size_mask as part of the device info, to indicate the page sizes supported by the HW. Currently only 4K is supported. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Mika Kuoppala

[Intel-gfx] [PATCH 00/21] huge gtt pages

Some updates to the kselftests as per Chris' comments. Matthew Auld (21): mm/shmem: introduce shmem_file_setup_with_mnt drm/i915: introduce simple gemfs drm/i915/gemfs: enable THP drm/i915: introduce page_size_mask to dev_info drm/i915: introduce page_size members drm/i915: introduce

  1   2   >