Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in modeset

> -Original Message- > From: Nikula, Jani > Sent: Wednesday, October 19, 2016 11:09 PM > To: Yang, Libin ; Lin, Mengdong > ; intel-gfx@lists.freedesktop.org > Cc: libin.y...@linux.intel.com; Pandiyan, Dhinakaran >

Re: [Intel-gfx] gvt gem fixes

On 2016.10.19 12:02:58 +0100, Chris Wilson wrote: > On Wed, Oct 19, 2016 at 06:45:51PM +0800, Zhenyu Wang wrote: > > On 2016.10.19 11:11:35 +0100, Chris Wilson wrote: > > > I think this is the set required to bring gvt into line, at least to > > > unblock myself. > > > > Thanks a lot, Chris. I'd

Re: [Intel-gfx] [PATCH] drm/i915/dp: Debug log MST active links explicitly

On Wed, 2016-10-19 at 08:47 +0100, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 05:18:48PM -0700, Dhinakaran Pandiyan wrote: > > From: "Pandiyan, Dhinakaran" > > > > No functional change. Just printing the number of active links without > > stating what the number

Re: [Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

On 2016.10.19 11:11:42 +0100, Chris Wilson wrote: > The workload took a pointer to the request, and even waited upon, > without holding a reference on the request. Take that reference > explicitly and fix up the error path following request allocation that > missed flushing the request. > >

Re: [Intel-gfx] [PATCH -next] drm/i915/gvt: fix return value check

On 2016.10.19 16:18:03 +, Wei Yongjun wrote: > From: Wei Yongjun > > In case of error, the function i915_gem_object_create() returns > ERR_PTR() not NULL. The NULL test in the return value check should > be replaced with IS_ERR(). > > Signed-off-by: Wei Yongjun

Re: [Intel-gfx] [PATCH RFC 2/8] drm: Define a work struct for scheduling a uevent for modeset retry

On Wed, 2016-10-19 at 14:46 -0700, Manasi Navare wrote: > This work struct will be used to schedule a uevent on a separate > thread. This will be scheduled after a link train failure during modeset > to indicate a modeset retry request. It will get executed after the > current modeset is complete

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Add a atomic evasion step to watermark programming.

On Wed, Oct 19, 2016 at 04:15:02PM -0700, Matt Roper wrote: > On Wed, Oct 12, 2016 at 03:28:18PM +0200, Maarten Lankhorst wrote: > > Allow the driver to write watermarks during atomic evasion. > > This will make it possible to write the watermarks in a cleaner > > way on gen9+. > > > >

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Add a atomic evasion step to watermark programming.

On Wed, Oct 12, 2016 at 03:28:18PM +0200, Maarten Lankhorst wrote: > Allow the driver to write watermarks during atomic evasion. > This will make it possible to write the watermarks in a cleaner > way on gen9+. > > Signed-off-by: Maarten Lankhorst > --- >

Re: [Intel-gfx] [PATCH 4/8] drm/i915/skl+: Clean up minimum allocations.

On Wed, Oct 12, 2016 at 03:28:17PM +0200, Maarten Lankhorst wrote: > Move calculating minimum allocations to a helper, which cleans up the > code some more. The cursor is still allocated in advance because it > doesn't count towards data rate and should always be reserved. > > Signed-off-by:

[Intel-gfx] ✗ Fi.CI.BAT: failure for Hotplug Uevent on Link training failure on DP

== Series Details == Series: Hotplug Uevent on Link training failure on DP URL : https://patchwork.freedesktop.org/series/14057/ State : failure == Summary == Series 14057v1 Hotplug Uevent on Link training failure on DP https://patchwork.freedesktop.org/api/1.0/series/14057/revisions/1/mbox/

Re: [Intel-gfx] [PATCH 3/8] drm/i915/skl+: Remove minimum block allocation from crtc state.

On Wed, Oct 12, 2016 at 03:28:16PM +0200, Maarten Lankhorst wrote: > This is not required any more now that we get fresh state from > drm_atomic_crtc_state_for_each_plane_state. Zero all state > in advance. > > Signed-off-by: Maarten Lankhorst Reviewed-by:

Re: [Intel-gfx] [PATCH 1/8] drm/i915/skl+: Prepare for removing data rate from skl watermark state

On Wed, Oct 12, 2016 at 03:28:14PM +0200, Maarten Lankhorst wrote: > Caching is not required, drm_atomic_crtc_state_for_each_plane_state > can be used to inspect all plane_states that are assigned to the > current crtc_state, so we can just recalculate every time. > > Signed-off-by: Maarten

Re: [Intel-gfx] [PATCH 2/8] drm/i915/skl+: Remove data_rate from watermark struct.

On Wed, Oct 12, 2016 at 03:28:15PM +0200, Maarten Lankhorst wrote: > It's only used in one function, and can be calculated without caching it > in the global struct by using drm_atomic_crtc_state_for_each_plane_state. > > Signed-off-by: Maarten Lankhorst > ---

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)

== Series Details == Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2) URL : https://patchwork.freedesktop.org/series/11667/ State : warning == Summary == Series 11667v2 drm/i915/dp: add lane_count check in intel_dp_check_link_status

[Intel-gfx] [PATCH RFC 4/8] drm/i915: Change the placement of some static functions in intel_dp.c

From: "Navare, Manasi D" These static helper functions are required to be used during fallback link rate implemnetation so they need to be placed at the top of the file. v3: * Add cleanup to other patch (Mika Kahola) v2: * Dont move around functions declared in

[Intel-gfx] [PATCH RFC 5/8] drm/i915; Add a function to return index of link rate

This is required to return the index of link rate into common_rates array. This gets used to retry the link training at lower link rate. Cc: Jani Nikula Cc: Daniel Vetter Cc: Ville Syrjala Signed-off-by:

[Intel-gfx] [PATCH RFC 0/8] Hotplug Uevent on Link training failure on DP

These patches handle the DP link training failure during atomic modeset. A new connector property is defined to indicate if link training retry is requested on failure. If link training fails, we set this connector property and send a hotplug uevent that gets exceuted after the current modeset is

[Intel-gfx] [PATCH RFC 3/8] drm: Trigger a complete modeset if link_train_retry is set

The link_train_retry property of the connector needs to be checked to see if a full modeset is required. If this is set, then link train retry is requested possibly due to linktrain failure in the previous modeset. Hence we need to indicate connector status changed in order to trigger a full

[Intel-gfx] [PATCH RFC 7/8] drm/i915: Link Rate fallback on Link training failure

If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed and use a lower link rate to prune the modes during the next modeset, configure the

[Intel-gfx] [PATCH RFC 6/8] drm/i915: Define the modeset retry work function

This work function gets scheduled on link training failure during the atomic commit of modeset. It should get executed after the current modeset is completed and send a hotplug uevent to notify the usersapce about change in the connector link property requesting link_train_retry Cc: Jani Nikula

[Intel-gfx] [PATCH RFC 2/8] drm: Define a work struct for scheduling a uevent for modeset retry

This work struct will be used to schedule a uevent on a separate thread. This will be scheduled after a link train failure during modeset to indicate a modeset retry request. It will get executed after the current modeset is complete and all locks are released. This was required to avoid deadlock.

[Intel-gfx] [PATCH RFC 8/8] drm/i915: Add support for DP link training compliance

This patch adds support to handle automated DP compliance link training test requests. This patch has been tested with Unigraf DPR-120 DP Compliance device for testing Link Training Compliance. After we get a short pulse Compliance test request, test request values are read and hotplug uevent is

[Intel-gfx] [PATCH RFC 1/8] drm: Add a link_train_retry field to drm_connector

This is a boolean that is set to true if link training fails during modeset in the atomic commit. This will be used to detect a change in the connector properties and to retrigger a full modeset so that the link can be retrained at lower link rate value. Cc: dri-de...@lists.freedesktop.org Cc:

[Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

Currently it's entirely possible to go through the link training step without first determining the lane_count, which is silly since we end up doing a bunch of aux transfers of size = 0, as highlighted by WARN_ON(!msg->buffer != !msg->size), and can only ever result in a 'failed to update link

[Intel-gfx] [PATCH igt] igt: drop gem_storedw_loop from BAT

The inter-engine synchronisation (with and without semaphores) is equally exercised by gem_sync, so leave gem_storedw_loop out of the "quick" set. Signed-off-by: Chris Wilson --- tests/gem_storedw_loop.c | 6 +++--- tests/intel-ci/fast-feedback.testlist |

Re: [Intel-gfx] [PATCH] drm/i915: STOP_MACHINE is no more, stop selecting it

On Wed, Oct 19, 2016 at 09:48:02PM +0300, Ville Syrjälä wrote: > On Wed, Oct 19, 2016 at 07:06:35PM +0100, Chris Wilson wrote: > > With the merge of 4.9-rc1, we can say goodbye to having to forcibly > > select STOP_MACHINE in order to have a working stop_machine(). The code > > just works now and

Re: [Intel-gfx] [PATCH] drm/i915: STOP_MACHINE is no more, stop selecting it

On Wed, Oct 19, 2016 at 07:06:35PM +0100, Chris Wilson wrote: > With the merge of 4.9-rc1, we can say goodbye to having to forcibly > select STOP_MACHINE in order to have a working stop_machine(). The code > just works now and the CONFIG_STOP_MACHINE symbol removed. Note the relevant commit too?

Re: [Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

On Wed, Oct 19, 2016 at 07:16:39PM +0100, Chris Wilson wrote: > On Wed, Oct 19, 2016 at 09:02:04PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Using spin_lock_irq()/spin_unlock_irq() from within the interrupt > > handler is a no-no.

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: fix return value check

== Series Details == Series: drm/i915/gvt: fix return value check URL : https://patchwork.freedesktop.org/series/14033/ State : warning == Summary == Series 14033v1 drm/i915/gvt: fix return value check https://patchwork.freedesktop.org/api/1.0/series/14033/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

On Wed, Oct 19, 2016 at 09:02:04PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Using spin_lock_irq()/spin_unlock_irq() from within the interrupt > handler is a no-no. Let's save/restore the flags to avoid turning on > interrupts

[Intel-gfx] [PATCH] drm/i915: STOP_MACHINE is no more, stop selecting it

With the merge of 4.9-rc1, we can say goodbye to having to forcibly select STOP_MACHINE in order to have a working stop_machine(). The code just works now and the CONFIG_STOP_MACHINE symbol removed. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig | 1 - 1

[Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

From: Ville Syrjälä Using spin_lock_irq()/spin_unlock_irq() from within the interrupt handler is a no-no. Let's save/restore the flags to avoid turning on interrupts prematurely. We hit this in a bunch of our CI systems, but for whatever reason I wasn't able to

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Handle early failure during intel_get_load_detect_pipe

On Wed, Oct 19, 2016 at 05:47:39PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Handle early failure during intel_get_load_detect_pipe > URL : https://patchwork.freedesktop.org/series/14016/ > State : warning > > == Summary == > > Series 14016v1 drm/i915: Handle early

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Handle early failure during intel_get_load_detect_pipe

== Series Details == Series: drm/i915: Handle early failure during intel_get_load_detect_pipe URL : https://patchwork.freedesktop.org/series/14016/ State : warning == Summary == Series 14016v1 drm/i915: Handle early failure during intel_get_load_detect_pipe

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Enable support for nonblocking modeset.

== Series Details == Series: drm/i915: Enable support for nonblocking modeset. URL : https://patchwork.freedesktop.org/series/14026/ State : failure == Summary == Series 14026v1 drm/i915: Enable support for nonblocking modeset.

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

On 10/19/2016 10:01 AM, Michal Hocko wrote: > The question I had earlier was whether this has to be an explicit FOLL > flag used by g-u-p users or we can just use it internally when mm != > current->mm The reason I chose not to do that was that deferred work gets run under a basically random

Re: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

On Tue, Sep 06, 2016 at 05:43:44PM +0300, Ville Syrjälä wrote: > On Sat, Aug 27, 2016 at 02:33:25PM +0100, Matthew Auld wrote: > > Currently it's entirely possible to go through the link training step > > without first determining the lane_count, which is silly since we end up > > doing a bunch of

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

On Wed 19-10-16 09:49:43, Dave Hansen wrote: > On 10/19/2016 02:07 AM, Michal Hocko wrote: > > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote: > >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: > >>> I am wondering whether we can go further. E.g. it is not really clear to > >>> me

[Intel-gfx] ✗ Fi.CI.BAT: failure for Broxton ddi phy refactoring (rev5)

== Series Details == Series: Broxton ddi phy refactoring (rev5) URL : https://patchwork.freedesktop.org/series/13320/ State : failure == Summary == Series 13320v5 Broxton ddi phy refactoring https://patchwork.freedesktop.org/api/1.0/series/13320/revisions/5/mbox/ Test

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

On 10/19/2016 02:07 AM, Michal Hocko wrote: > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote: >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote: >>> I am wondering whether we can go further. E.g. it is not really clear to >>> me whether we need an explicit FOLL_REMOTE when we can in

Re: [Intel-gfx] [PATCH] drm/i915: Add i915 perf infrastructure

On Wed, Oct 12, 2016 at 12:41 PM, Joonas Lahtinen < joonas.lahti...@linux.intel.com> wrote: > On ti, 2016-10-11 at 12:03 -0700, Robert Bragg wrote: > > > > + case DRM_I915_PERF_PROP_MAX: > > > > + BUG(); > > > > > > We already handle this case above, but I

[Intel-gfx] [PATCH -next] drm/i915/gvt: fix return value check

From: Wei Yongjun In case of error, the function i915_gem_object_create() returns ERR_PTR() not NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by: Wei Yongjun --- drivers/gpu/drm/i915/gvt/cmd_parser.c

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Stop reporting error details in dmesg as well as the error-state

== Series Details == Series: drm/i915: Stop reporting error details in dmesg as well as the error-state URL : https://patchwork.freedesktop.org/series/14021/ State : failure == Summary == Series 14021v1 drm/i915: Stop reporting error details in dmesg as well as the error-state

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c

On Wed, 19 Oct 2016, Ander Conselvan De Oliveira wrote: > On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote: >> > + /** >> > +  * @hw_state: hardware configuration for the DPLL. >> "... stored in struct _dpll_hw_state." - I love my hyperlinks ;-) > > I'll add that,

Re: [Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

On Wed, 19 Oct 2016, Ville Syrjälä wrote: > On Wed, Oct 19, 2016 at 03:08:04PM +0300, Jani Nikula wrote: >> Fix warnings on building htmldocs. >> >> v2: whitespace around '/' (Ville) >> >> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") >> Cc:

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Fix LSPCON kernel-doc (rev2)

On Wed, 19 Oct 2016, Patchwork wrote: > == Series Details == > > Series: drm: Fix LSPCON kernel-doc (rev2) > URL : https://patchwork.freedesktop.org/series/14017/ > State : failure > > == Summary == > > Series 14017v2 drm: Fix LSPCON kernel-doc >

Re: [Intel-gfx] [PATCH 1/2] shmem: Support for registration of Driver/file owner specific ops

On Thu, Mar 24, 2016 at 5:41 PM, Joonas Lahtinen wrote: > On ke, 2016-03-23 at 11:39 +0530, akash.g...@intel.com wrote: >> From: Chris Wilson >> >> This provides support for the Drivers or shmem file owners to register >> a set of

Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in modeset

Sorry it's taken me forever to get back to this. Some comments inline. BR, Jani. On Wed, 12 Oct 2016, "Yang, Libin" wrote: >> -Original Message- >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >> Lin, Mengdong >> Sent: Wednesday,

Re: [Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

On Wed, Oct 19, 2016 at 03:08:04PM +0300, Jani Nikula wrote: > Fix warnings on building htmldocs. > > v2: whitespace around '/' (Ville) > > Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") > Cc: Rodrigo Vivi > Cc: Shashank Sharma

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Fix LSPCON kernel-doc (rev2)

== Series Details == Series: drm: Fix LSPCON kernel-doc (rev2) URL : https://patchwork.freedesktop.org/series/14017/ State : failure == Summary == Series 14017v2 drm: Fix LSPCON kernel-doc https://patchwork.freedesktop.org/api/1.0/series/14017/revisions/2/mbox/ Test gem_exec_suspend:

[Intel-gfx] [PATCH igt] igt/gem_tiled_pread_basic: Only print the erroneous location

Emitting a debug message for every pixel tested takes us from 0.4s to 20s on an old Core2. Signed-off-by: Chris Wilson --- tests/gem_tiled_pread_basic.c | 32 1 file changed, 20 insertions(+), 12 deletions(-) diff --git

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Handle early failure during intel_get_load_detect_pipe

== Series Details == Series: drm/i915: Handle early failure during intel_get_load_detect_pipe URL : https://patchwork.freedesktop.org/series/14016/ State : failure == Summary == Series 14016v1 drm/i915: Handle early failure during intel_get_load_detect_pipe

[Intel-gfx] [RESEND PATCH 1/6] drm/i915: Convert intel_hdmi to use atomic state

This is the last connector still looking at crtc->config. Fix this. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_hdmi.c | 48 +-- 1 file changed, 21 insertions(+), 27 deletions(-) diff --git

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [01/12] drm/i915/gvt: s/drm_gem_object_unreference/i915_gem_object_put/

== Series Details == Series: series starting with [01/12] drm/i915/gvt: s/drm_gem_object_unreference/i915_gem_object_put/ URL : https://patchwork.freedesktop.org/series/14013/ State : warning == Summary == Series 14013v1 Series without cover letter

[Intel-gfx] [RESEND PATCH 3/6] drm/edid: Remove drm_select_eld

The only user was i915, which is now gone. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_edid.c | 26 -- include/drm/drm_edid.h | 1 - 2 files changed, 27 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c

[Intel-gfx] [RESEND PATCH 5/6] drm/i915: Pass atomic state to verify_connector_state

This gets rid of a warning that the connectors are used without locking when doing a nonblocking modeset. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-)

[Intel-gfx] [RESEND PATCH 4/6] drm/i915: Update atomic modeset state synchronously

All of this state should be updated as soon as possible. It shouldn't be done later because then future updates may not depend on it. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 15 --- 1 file changed, 8

[Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

drm_select_eld requires mode_config.mutex and connection_mutex because it looks at the connector list and at the legacy encoders. This is not required, because when we call audio_codec_enable we know which connector it was called for, so pass the state. This also removes having to look at

[Intel-gfx] [RESEND PATCH 0/6] drm/i915: Enable support for nonblocking modeset.

This is a rebased version of the series. Patch 4 fails to apply because of drm_atomic_state refcounting, but otherwise unchanged. This series is tested on my BDW and SKL. Skylake requires Lyude's fixes + "[PATCH 0/8] drm/i915/gen9+: Atomic wm fixes." Maarten Lankhorst (6): drm/i915: Convert

[Intel-gfx] [RESEND PATCH 6/6] drm/i915: Enable support for nonblocking modeset

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 54a4b2704179..523bb97c3bca 100644 ---

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Add runtime pm around fences

== Series Details == Series: drm/i915/gvt: Add runtime pm around fences URL : https://patchwork.freedesktop.org/series/14011/ State : warning == Summary == Series 14011v1 drm/i915/gvt: Add runtime pm around fences https://patchwork.freedesktop.org/api/1.0/series/14011/revisions/1/mbox/ Test

Re: [Intel-gfx] IGT contributions and reviews

On Wed, Oct 19, 2016 at 1:26 PM, Jani Nikula wrote: > On Wed, 19 Oct 2016, Daniel Vetter wrote: >> On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote: >>> On Tue, 18 Oct 2016, Petri Latvala wrote: >>> > The current

Re: [Intel-gfx] IGT contributions and reviews

On Wed, 19 Oct 2016, Paulo Zanoni wrote: > Why is Daniel asking me to submit patches to the mailing list if that > guy doesn't seem to need to follow the same rule? Is this some sort of > double- standard?". Not to take anything away from a perfectly good rant, but from

Re: [Intel-gfx] IGT contributions and reviews

On Wed, Oct 19, 2016 at 3:06 PM, Paulo Zanoni wrote: >> > > At the very least I would like to see all commits have a visit to >> > > the >> > > mailing list before pushing, as the current docs already ask for. >> > > The >> > > "right after" part would be changed to a

[Intel-gfx] [PATCH igt] igt: Check the physical swizzle status

The kernel tries to hide L-shaped memory with asymmetric swizzling from userspace by reporting lies through the get-tiling interface. Check for these lies by comparing the reported swizzle with the actual swizzle, and only run swizzling tests where we know the underlying physical swizzling.

Re: [Intel-gfx] IGT contributions and reviews

Em Qua, 2016-10-19 às 09:50 +0200, Daniel Vetter escreveu: > On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote: > > > > On Tue, 18 Oct 2016, Petri Latvala wrote: > > > > > > The current contributing docs for IGT state: > > > > > > << > > >   There is no

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Hold a reference on the request

== Series Details == Series: drm/i915/gvt: Hold a reference on the request URL : https://patchwork.freedesktop.org/series/14009/ State : failure == Summary == Series 14009v1 drm/i915/gvt: Hold a reference on the request https://patchwork.freedesktop.org/api/1.0/series/14009/revisions/1/mbox/

[Intel-gfx] [PATCH] drm/i915: Stop reporting error details in dmesg as well as the error-state

As we already capture all the information from the registers into the error-state, also dumping that to dmesg just generates noise that upsets CI and users alike (and doesn't provide us with any more information). Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

Fix warnings on building htmldocs. v2: whitespace around '/' (Ville) Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") Cc: Rodrigo Vivi Cc: Shashank Sharma Cc: Signed-off-by: Jani Nikula

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c

On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote: > On Tue, Oct 04, 2016 at 03:32:15PM +0300, Ander Conselvan de Oliveira wrote: > > > > The documentation for most of the non-static members and structs were > > missing. Fix that. > > > > v2: Fix typos (Durga) > > > > v3: Rebase. > >

Re: [Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

On Wed, Oct 19, 2016 at 02:43:24PM +0300, Jani Nikula wrote: > Fix warnings on building htmldocs. > > Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") > Cc: Rodrigo Vivi > Cc: Shashank Sharma > Cc:

[Intel-gfx] [PATCH] drm: Fix LSPCON kernel-doc

Fix warnings on building htmldocs. Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") Cc: Rodrigo Vivi Cc: Shashank Sharma Cc: Signed-off-by: Jani Nikula --- n.b.

[Intel-gfx] [PATCH] drm/i915: Handle early failure during intel_get_load_detect_pipe

In the error path, we have to be ready to handle an error before either the state or restore_state have been allocated. [ 397.001342] BUG: unable to handle kernel NULL pointer dereference at (null) [ 397.001419] IP: [] intel_get_load_detect_pipe+0xe4/0x610 [i915] [ 397.001502] PGD

Re: [Intel-gfx] IGT contributions and reviews

On Wed, 19 Oct 2016, Daniel Vetter wrote: > On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote: >> On Tue, 18 Oct 2016, Petri Latvala wrote: >> > The current contributing docs for IGT state: >> > >> > << >> > There is no formal review

Re: [Intel-gfx] [PATCH 1/2] drm: make is_lspcon_adaptor static

On Tue, 18 Oct 2016, "Sharma, Shashank" wrote: > Reviewed-by: Shashank Sharma Both pushed to drm-intel-next-queued, thanks for the review. RB, Jani. > > Regards > Shashank > -Original Message- > From: Nikula, Jani > Sent: Tuesday, October 18, 2016 4:52 PM >

Re: [Intel-gfx] [PATCH] drm: fix sparse warnings on undeclared symbols in crc debugfs

On Tue, 18 Oct 2016, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 02:28:35PM +0300, Jani Nikula wrote: >> Fixes sparse warnings: >> >> drivers/gpu/drm/drm_debugfs_crc.c:118:30: warning: symbol >> 'drm_crtc_crc_control_fops' was not declared. Should it be static? >> >>

Re: [Intel-gfx] gvt gem fixes

On Wed, Oct 19, 2016 at 06:45:51PM +0800, Zhenyu Wang wrote: > On 2016.10.19 11:11:35 +0100, Chris Wilson wrote: > > I think this is the set required to bring gvt into line, at least to > > unblock myself. > > Thanks a lot, Chris. I'd like to merge this in next pull request, > or let me know you

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread (rev2)

== Series Details == Series: series starting with [1/2] drm/i915/gvt: Stop checking for impossible interrupts from a kthread (rev2) URL : https://patchwork.freedesktop.org/series/14004/ State : failure == Summary == Series 14004v2 Series without cover letter

Re: [Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

On Wed, Oct 19, 2016 at 06:32:54PM +0800, Zhenyu Wang wrote: > On 2016.10.19 11:11:42 +0100, Chris Wilson wrote: > > The workload took a pointer to the request, and even waited upon, > > without holding a reference on the request. Take that reference > > explicitly and fix up the error path

Re: [Intel-gfx] gvt gem fixes

On 2016.10.19 11:11:35 +0100, Chris Wilson wrote: > I think this is the set required to bring gvt into line, at least to > unblock myself. Thanks a lot, Chris. I'd like to merge this in next pull request, or let me know you want to be picked up by drm-intel directly. If 4/12 would be picked up

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Make GPU pages movable

On ti, 2016-10-18 at 14:39 +0100, Chris Wilson wrote: > It's in my tree (on top of nightly) already with Joonas' r-b. Patch 1/2 seems to have my comments already, could be addressed and respined too. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [Intel-gfx] [PATCH 08/41] drm/i915: Rearrange i915_wait_request() accounting with callers

On ti, 2016-10-18 at 19:51 +0100, Matthew Auld wrote: > > > >   * Returns 0 if the request was found within the alloted time. > > Else returns the > >   * errno with remaining time filled in timeout argument. > >   */ > > -int i915_wait_request(struct drm_i915_gem_request *req, > > -  

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/4] drm/i915: Bump object bookkeeping to u64 from size_t

On Tue, Oct 18, 2016 at 05:46:48PM +, Saarinen, Jani wrote: > > On Tue, Oct 18, 2016 at 01:05:24PM -, Patchwork wrote: > > > == Series Details == > > > > > > Series: series starting with [CI,1/4] drm/i915: Bump object bookkeeping to > > u64 from size_t > > > URL :

Re: [Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

On 2016.10.19 11:11:42 +0100, Chris Wilson wrote: > The workload took a pointer to the request, and even waited upon, > without holding a reference on the request. Take that reference > explicitly and fix up the error path following request allocation that > missed flushing the request. > >

Re: [Intel-gfx] [PATCH 10/12] drm/i915/gvt: Use common mapping routines for indirect_ctx object

On 2016.10.19 11:11:45 +0100, Chris Wilson wrote: > We have the ability to map an object, so use it rather than opencode it > badly. > > Signed-off-by: Chris Wilson Planned to fix these mapping too, obviously not fast than you.. Reviewed-by: Zhenyu Wang

Re: [Intel-gfx] [PATCH 04/12] drm/i915: Catch premature unpinning of pages

On ke, 2016-10-19 at 11:11 +0100, Chris Wilson wrote: > Try to catch the violation of unpinning the backing storage whilst still > bound to the GPU. > > Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Regards, Joonas --

[Intel-gfx] [PATCH 12/12] drm/i915/gvt: Remove defunct vmap_batch()

This code was removed from i915_cmd_parser.c but still an obsolete version wound up being duplicated into gvt/cmd_parser.c. Good riddance. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/cmd_parser.c | 38 --- 1 file changed, 38

[Intel-gfx] [PATCH 10/12] drm/i915/gvt: Use common mapping routines for indirect_ctx object

We have the ability to map an object, so use it rather than opencode it badly. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/cmd_parser.c | 28 +--- drivers/gpu/drm/i915/gvt/execlist.c | 2 +- 2 files changed, 10 insertions(+), 20

[Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

The workload took a pointer to the request, and even waited upon, without holding a reference on the request. Take that reference explicitly and fix up the error path following request allocation that missed flushing the request. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 06/12] drm/i915/gvt: Remove dangerous unpin of backing storage of bound GPU object

Unpinning the pages prior to the object being release from the GPU may allow the GPU to read and write into system pages (i.e. use after free by the hw). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/execlist.c | 12 ++-- 1 file changed, 10

[Intel-gfx] [PATCH 01/12] drm/i915/gvt: s/drm_gem_object_unreference/i915_gem_object_put/

Deprecated functions; it is also not clear whether these are called from the right context. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/execlist.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/execlist.c

[Intel-gfx] [PATCH 05/12] drm/i915/gvt: Use the returned VMA to provide the virtual address

The purpose of returning the just-pinned VMA is so that we can use the information within, like its address. Also it should be tracked and used as the cookie to unpin... Signed-off-by: Chris Wilson Reviewed-by: Zhenyu Wang ---

[Intel-gfx] [PATCH 08/12] drm/i915/gvt: Stop checking for impossible interrupts from a kthread

The kthread will not be interrupted, don't even bother checking. Signed-off-by: Chris Wilson Reviewed-by: Zhenyu Wang --- drivers/gpu/drm/i915/gvt/scheduler.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git

[Intel-gfx] [PATCH 09/12] drm/i915/gvt: Stop waiting whilst holding struct_mutex

For whatever reason, the gvt scheduler runs synchronously. At the very least, lets run synchronously without holding the struct_mutex. v2: cut'n'paste mutex_lock instead of unlock. Replace long hold of struct_mutex with a mutex to serialise the worker threads. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 02/12] drm/i915/gvt: Add runtime pm around fences

Manipulating the fence_list requires the runtime wakelock, as does writing to the fence registers. Acquire a wakelock for the former, and assert that the device is awake for the latter. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/aperture_gm.c | 10

[Intel-gfx] [PATCH 11/12] drm/i915/gvt: Use common mapping routines for shadow_bb object

We have the ability to map an object, so use it rather than opencode it badly. Note that the object remains permanently pinned, this is poor practise. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/cmd_parser.c | 21 ++---

[Intel-gfx] [PATCH 04/12] drm/i915: Catch premature unpinning of pages

Try to catch the violation of unpinning the backing storage whilst still bound to the GPU. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH 03/12] drm/i915/gvt: i915_gem_object_create() returns an error pointer

On failure from i915_gem_object_create(), we need to check for an error pointer not NULL. Signed-off-by: Chris Wilson Reviewed-by: Zhenyu Wang --- drivers/gpu/drm/i915/gvt/cmd_parser.c | 48 --- 1 file changed,

[Intel-gfx] gvt gem fixes

I think this is the set required to bring gvt into line, at least to unblock myself. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/gvt: Add runtime pm around fences

Manipulating the fence_list requires the runtime wakelock, as does writing to the fence registers. Acquire a wakelock for the former, and assert that the device is awake for the latter. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/aperture_gm.c | 10

  1   2   >