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

Hey, Op 20-10-16 om 01:15 schreef Matt Roper: > 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

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

On Tue, Oct 18, 2016 at 01:48:52PM +0100, Chris Wilson wrote: > On Tue, Oct 18, 2016 at 03:41:54PM +0300, Petri Latvala wrote: > > How should vgem work be flushed properly? With this i915 flushing is > > guaranteed even if vgem is opened first, then i915, but such > > flushing won't be done if

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 06:55:44PM +0100, Chris Wilson wrote: > 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/ > >

Re: [Intel-gfx] gvt gem fixes

On Thu, Oct 20, 2016 at 08:33:05AM +0800, Zhenyu Wang wrote: > 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,

Re: [Intel-gfx] gvt gem fixes

On 2016.10.20 09:02:45 +0200, Daniel Vetter wrote: > Yeah, I think anything that touches i915 code should get merged through > drm-intel directly with the usual process. Only exception is when gvt has > a functional depency and it's a small patch, then I think we can sometimes > merge i915 core

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

On Wed, Oct 19, 2016 at 06:29:13PM +0300, Jani Nikula wrote: > 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. > >> "...

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

On Thu, Oct 20, 2016 at 08:22:00AM +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] [PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

Lorenzo Stoakes writes: > diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c > index f52b7db3..010b7b3 100644 > --- a/arch/powerpc/kernel/ptrace32.c > +++ b/arch/powerpc/kernel/ptrace32.c > @@ -74,7 +74,7 @@ long compat_arch_ptrace(struct task_struct

[Intel-gfx] [PATCH] i915: don't call drm_atomic_state_put on invalid pointer

The introduction of reference counting on the state structures caused sanitize_watermarks() in i915 to break in the error handling case, as pointed out by gcc -Wmaybe-uninitialized drivers/gpu/drm/i915/intel_display.c: In function ‘intel_modeset_init’: include/drm/drm_atomic.h:224:2: error:

Re: [Intel-gfx] [PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

On Thu, Oct 13, 2016 at 01:20:20AM +0100, Lorenzo Stoakes wrote: > This patch removes the write parameter from access_process_vm() and replaces > it > with a gup_flags parameter as use of this function previously _implied_ > FOLL_FORCE, whereas after this patch callers explicitly pass this flag.

[Intel-gfx] Intel DRM Driver - Weathered Colours Patch

Hello All, Please find a proposed workaround patch for a weathered colours (incorrect assignment to Limited RGB setting) issue. The weathered colour issue is documented at: https://bugs.archlinux.org/task/46472

Re: [Intel-gfx] [PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags

On Thu, Oct 13, 2016 at 01:20:16AM +0100, Lorenzo Stoakes wrote: > This patch removes the write and force parameters from get_user_pages() and > replaces them with a gup_flags parameter to make the use of FOLL_FORCE > explicit > in callers as use of this flag can result in surprising behaviour

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: clean up intel_gvt.h as interface for i915 core (rev3)

== Series Details == Series: drm/i915/gvt: clean up intel_gvt.h as interface for i915 core (rev3) URL : https://patchwork.freedesktop.org/series/14078/ State : failure == Summary == Series 14078v3 drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

On 2016.10.20 11:01:02 +0100, Chris Wilson wrote: > On Thu, Oct 20, 2016 at 05:42:37PM +0800, Zhenyu Wang wrote: > > On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote: > > > On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote: > > > > > > > > We need to formalize the process between i915

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

Chris Wilson writes: > 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

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

On Thu, Oct 20, 2016 at 01:47:28PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > 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

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

On Thu, 20 Oct 2016, Zhenyu Wang wrote: > On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote: >> On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote: >> > * GVT-g bug management. Do you have something set up already? Would be >> > great to be able to use

[Intel-gfx] [PATCH] drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

When invalidating RCS TLB the device can enter RC6 state interrupting the process, therefore the need for render forcewake for the whole procedure. This WA is needed for all production SKL SKUs. References: HSD#2136899, HSD#1404391274 Cc: Mika Kuoppala Cc: Zhenyu Wang

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

On Thu, Oct 20, 2016 at 01:52:32PM +0200, Arkadiusz Hiler wrote: > On Thu, Oct 20, 2016 at 11:17:09AM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate > > URL : https://patchwork.freedesktop.org/series/14097/ > >

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

On Thu, Oct 20, 2016 at 05:42:37PM +0800, Zhenyu Wang wrote: > On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote: > > On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote: > > > > > > We need to formalize the process between i915 proper and GVT-g a bit > > > more, and address some of the

Re: [Intel-gfx] [PATCH] drm: Complete CEA modedb(VIC 1-107)

Adding Jose and Daniel in cc. Regards Shashank -Original Message- From: Sharma, Shashank Sent: Thursday, October 20, 2016 3:58 PM To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org Cc: airl...@redhat.com; =daniel.vet...@intel.com; jose.ab...@synopsys.com; Sharma,

[Intel-gfx] [PATCH dim] dim-update-next: Update DRIVER_TIMESTAMP

Along with the DRIVER_DATE, also update the DRIVER_TIMESTAMP as measured in seconds from the start of the epoch. Signed-off-by: Chris Wilson Cc: Daniel Vetter --- dim | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dim b/dim

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

On Thu, 20 Oct 2016, "Yang, Libin" wrote: >> >> Any particular reason these M/N values are half of what they're in >> >> table >> >> 2-104 of DP 1.4 spec? (Admittedly the table is an informative >> >> example.) >> > >> > For HDMI, we found only set N is enough. HW then can

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

On Thu, Oct 20, 2016 at 02:34:34PM +0300, Jani Nikula wrote: > On Thu, 20 Oct 2016, "Yang, Libin" wrote: > >> >> Any particular reason these M/N values are half of what they're in > >> >> table > >> >> 2-104 of DP 1.4 spec? (Admittedly the table is an informative > >> >>

Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Use manual error-state generation

On Thu, Oct 20, 2016 at 10:46:01AM +0100, Chris Wilson wrote: > On Thu, Oct 20, 2016 at 11:29:05AM +0200, Daniel Vetter wrote: > > On Thu, Oct 20, 2016 at 10:07:39AM +0100, Chris Wilson wrote: > > > For the basic error state, we only desire that an error state be created > > > following a hang.

[Intel-gfx] [PULL] GVT-g device model core fixes

Hi, This is second pull request for GVT-g sub module which contains fixes for issues within first pull request. Regression test has been passed combining this new pull request with unmerged driver facilities to test for VMs. Thanks. -- The following changes since commit

[Intel-gfx] [PATCH] drm: Complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new 4k video modes to be used with HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the way till VIC=107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse 4k modes using the existing techniques, we have to complete the modedb

Re: [Intel-gfx] [PATCH 06/41] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

On Mon, Oct 17, 2016 at 03:20:14PM +0300, Joonas Lahtinen wrote: > On pe, 2016-10-14 at 13:17 +0100, Chris Wilson wrote: > > We will need to wait on DMA completion (as signaled via struct fence) > > before executing our i915_gem_request. Therefore we want to expose a > > method for adding the

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

Chris Wilson writes: > On Thu, Oct 20, 2016 at 01:47:28PM +0300, Mika Kuoppala wrote: >> Chris Wilson writes: >> >> > As we already capture all the information from the registers into the >> > error-state, also dumping that to dmesg just

[Intel-gfx] [bug report] drm/i915/gvt: vGPU command scanner

Hello Zhi Wang, The patch be1da7070aea: "drm/i915/gvt: vGPU command scanner" from May 3, 2016, leads to the following static checker warning: drivers/gpu/drm/i915/gvt/cmd_parser.c:1420 cmd_handler_mi_op_2f() warn: shift has higher precedence than mask

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

On Thu, Oct 20, 2016 at 11:17:09AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate > URL : https://patchwork.freedesktop.org/series/14097/ > State : warning > > == Summary == > > Series 14097v1 drm/i915/gvt: Implement

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Complete CEA modedb(VIC 1-107)

== Series Details == Series: drm: Complete CEA modedb(VIC 1-107) URL : https://patchwork.freedesktop.org/series/14090/ State : warning == Summary == Series 14090v1 drm: Complete CEA modedb(VIC 1-107) https://patchwork.freedesktop.org/api/1.0/series/14090/revisions/1/mbox/ Test gem_busy:

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

== Series Details == Series: drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate URL : https://patchwork.freedesktop.org/series/14097/ State : warning == Summary == Series 14097v1 drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

Re: [Intel-gfx] [PATCH] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

On Thu, Oct 20, 2016 at 03:29:13PM +0800, Zhenyu Wang wrote: > @@ -214,9 +215,15 @@ int intel_gvt_init_device(struct drm_i915_private > *dev_priv) > if (WARN_ON(!intel_gvt_host.initialized)) > return -EINVAL; > > - if (WARN_ON(gvt->initialized)) > + if

[Intel-gfx] [PATCH 2/5] drm/i915: Use RPM as the barrier for controlling user mmap access

We can remove the false coupling between RPM and struct mutex by the observation that we can use the RPM wakeref as the barrier around user mmap access. That is as we tear down the user's PTE atomically from within rpm suspend and then to fault in new PTE requires the rpm wakeref, means that no

[Intel-gfx] [PATCH 5/5] drm/i915: Move fence cancellation to runtime suspend

At the moment, we have dependency on the RPM as a barrier itself in both i915_gem_release_all_mmaps() and i915_gem_restore_fences(). i915_gem_restore_fences() is also called along !runtime pm paths, but we can move the markup of lost fences alongside releasing the mmaps into a common

[Intel-gfx] [PATCH v2] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

i915 core should only call functions and structures exposed through intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h. Change for internal intel_gvt structure as private handler which not requires to expose gvt internal structure for i915 core. v2: Fix per Chris's comment - carefully handle

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

On Thu, Oct 20, 2016 at 04:26:14PM +0800, Zhenyu Wang wrote: > int intel_gvt_init_device(struct drm_i915_private *dev_priv) > { > - struct intel_gvt *gvt = _priv->gvt; > + struct intel_gvt *gvt; > int ret; > > /* > @@ -214,9 +216,13 @@ int intel_gvt_init_device(struct

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

On Thu, 2016-10-20 at 11:19 +0300, Jani Nikula wrote: > On Thu, 20 Oct 2016, Daniel Vetter wrote: > > > > On Wed, Oct 19, 2016 at 06:29:13PM +0300, Jani Nikula wrote: > > > > > > On Wed, 19 Oct 2016, Ander Conselvan De Oliveira > > > wrote: > > > > > > >

[Intel-gfx] i915 and GTV-g maintenance, workflows and CI

We need to formalize the process between i915 proper and GVT-g a bit more, and address some of the current shortcomings and issues in the process and GVT-g CI. This started off internally as a random list of items, I'm including some of the current status as well. Please comment, as some of the

[Intel-gfx] [PATCH igt] igt/drv_hangman: Use manual error-state generation

For the basic error state, we only desire that an error state be created following a hang. For that purpose, we do not need a real hang (slow 6-12s) but can inject one instead (fast <1s). Signed-off-by: Chris Wilson --- tests/drv_hangman.c | 14 +++--- 1 file

[Intel-gfx] [PATCH] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

i915 core should only call functions and structures exposed through intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h. Change for internal intel_gvt structure as private handler which not requires to expose gvt internal structure for i915 core. Signed-off-by: Zhenyu Wang

[Intel-gfx] [PATCH] Documentation/gpu: Add section for Intel GVT-g host support

Update with brief overview and reference for more detailed arch design documents. Add new section for Intel GVT-g host support. Signed-off-by: Zhenyu Wang --- Documentation/gpu/i915.rst | 9 + drivers/gpu/drm/i915/intel_gvt.c | 8 ++-- 2 files

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

On Thu, Oct 20, 2016 at 04:02:39PM +0800, Zhenyu Wang wrote: > void intel_gvt_clean_device(struct drm_i915_private *dev_priv) > { > - struct intel_gvt *gvt = _priv->gvt; > + struct intel_gvt *gvt = to_gvt(dev_priv); > > if (WARN_ON(!gvt->initialized)) > return; > @@

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

On Thu, 20 Oct 2016, Daniel Vetter wrote: > On Wed, Oct 19, 2016 at 06:29:13PM +0300, Jani Nikula wrote: >> On Wed, 19 Oct 2016, Ander Conselvan De Oliveira >> wrote: >> > On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote: >> >> > + /** >> >> >

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

On Wed, Oct 19, 2016 at 10:29:53PM +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 aux transfers of size = 0, as highlighted by > WARN_ON(!msg->buffer !=

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

On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote: > The inter-engine synchronisation (with and without semaphores) is > equally exercised by gem_sync, so leave gem_storedw_loop out of the > "quick" set. How equally is "equally"? Is the test actually redundant, should it be removed

Re: [Intel-gfx] gvt gem fixes

On Thu, Oct 20, 2016 at 03:15:33PM +0800, Zhenyu Wang wrote: > On 2016.10.20 09:02:45 +0200, Daniel Vetter wrote: > > Yeah, I think anything that touches i915 code should get merged through > > drm-intel directly with the usual process. Only exception is when gvt has > > a functional depency and

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

On 2016.10.20 09:12:02 +0100, Chris Wilson wrote: > On Thu, Oct 20, 2016 at 04:02:39PM +0800, Zhenyu Wang wrote: > > void intel_gvt_clean_device(struct drm_i915_private *dev_priv) > > { > > - struct intel_gvt *gvt = _priv->gvt; > > + struct intel_gvt *gvt = to_gvt(dev_priv); > > > > if

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

Op 20-10-16 om 00:13 schreef Matt Roper: > 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

[Intel-gfx] [PATCH v3] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

i915 core should only call functions and structures exposed through intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h. Change for internal intel_gvt structure as private handler which not requires to expose gvt internal structure for i915 core. v2: Fix per Chris's comment - carefully handle

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

On Thu, 20 Oct 2016, "Yang, Libin" wrote: >> -Original Message- >> From: Nikula, Jani >> Sent: Wednesday, October 19, 2016 11:09 PM >> To: Yang, Libin ; Lin, Mengdong >> ; intel-gfx@lists.freedesktop.org >> Cc:

Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Use manual error-state generation

On Thu, Oct 20, 2016 at 10:07:39AM +0100, Chris Wilson wrote: > For the basic error state, we only desire that an error state be created > following a hang. For that purpose, we do not need a real hang (slow > 6-12s) but can inject one instead (fast <1s). > > Signed-off-by: Chris Wilson

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

On Thu, Oct 20, 2016 at 11:16:16AM +0200, Daniel Vetter wrote: > On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote: > > On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote: > > > On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote: > > > > The inter-engine

Re: [Intel-gfx] [PATCH 23/41] drm/i915: Move object release to a freelist + worker

On Tue, Oct 18, 2016 at 10:51:53AM +0100, John Harrison wrote: > On 14/10/2016 13:18, Chris Wilson wrote: > >@@ -338,11 +345,10 @@ i915_gem_get_tiling(struct drm_device *dev, void *data, > > case I915_TILING_Y: > > args->swizzle_mode = dev_priv->mm.bit_6_swizzle_y; > >

[Intel-gfx] [PATCH 4/5] drm/i915: Remove RPM sequence checking

We only used the RPM sequence checking inside the lowlevel GTT accessors, when we had to rely on callers taking the wakeref on our behalf. Now that we take the RPM wakeref inside the GTT management routines themselves, we can forgo the sanitycheck of the callers. Signed-off-by: Chris Wilson

[Intel-gfx] RPM vs struct mutex fixes

A little hiccup caught by 0day but not BAT having been resolved with commit ebc0808fa2da ("drm/i915: Restrict pagefault disabling to just around copy_from_user()"), let's try again. I'm still puzzling over how BAT missed the warning. -Chris ___

[Intel-gfx] [PATCH 1/5] drm/i915: Move user fault tracking to a separate list

We want to decouple RPM and struct_mutex, but currently RPM has to walk the list of bound objects and remove userspace mmapping before we suspend (otherwise userspace may continue to access the GTT whilst it is powered down). This currently requires the struct_mutex to walk the bound_list, but if

[Intel-gfx] [PATCH 3/5] drm/i915: Remove superfluous locking around userfault_list

Now that we have reduced the access to the list to either (a) under the struct_mutex whilst holding the RPM wakeref (so that concurrent writers to the list are serialised by struct_mutex) and (b) under the atomic runtime suspend (which cannot run concurrently with any other accessor due to the

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

On Thu, Oct 20, 2016 at 11:56:07AM +0300, Ander Conselvan De Oliveira wrote: > On Thu, 2016-10-20 at 11:19 +0300, Jani Nikula wrote: > > On Thu, 20 Oct 2016, Daniel Vetter wrote: > > > > > > On Wed, Oct 19, 2016 at 06:29:13PM +0300, Jani Nikula wrote: > > > > > > > > On Wed, 19

[Intel-gfx] [PATCH i-g-t v4] tests/kms_plane_multiple: CRC based atomic correctness test

This is a testcase with multiple planes. The idea here is the following - draw a uniform frame with blue color - grab crc for reference - put planes randomly on top with the same blue color - punch holes with black color into the primary framebuffer - ideally the planes should cover these

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

On 19 October 2016 at 22:47, Patchwork wrote: > == 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

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote: > On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote: > > > > We need to formalize the process between i915 proper and GVT-g a bit > > more, and address some of the current shortcomings and issues in the > > process and GVT-g CI. > > >

Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Use manual error-state generation

On Thu, Oct 20, 2016 at 11:29:05AM +0200, Daniel Vetter wrote: > On Thu, Oct 20, 2016 at 10:07:39AM +0100, Chris Wilson wrote: > > For the basic error state, we only desire that an error state be created > > following a hang. For that purpose, we do not need a real hang (slow > > 6-12s) but can

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

On 2016.10.20 07:52:18 +0100, Chris Wilson wrote: > On Thu, Oct 20, 2016 at 08:22:00AM +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

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

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for Intel DRM Driver - Weathered Colours Patch

== Series Details == Series: Intel DRM Driver - Weathered Colours Patch URL : https://patchwork.freedesktop.org/series/14077/ State : warning == Summary == Series 14077v1 Intel DRM Driver - Weathered Colours Patch https://patchwork.freedesktop.org/api/1.0/series/14077/revisions/1/mbox/ Test

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

On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote: > On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote: > > The inter-engine synchronisation (with and without semaphores) is > > equally exercised by gem_sync, so leave gem_storedw_loop out of the > > "quick" set. > > > How

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Move user fault tracking to a separate list

== Series Details == Series: series starting with [1/5] drm/i915: Move user fault tracking to a separate list URL : https://patchwork.freedesktop.org/series/14080/ State : warning == Summary == Series 14080v1 Series without cover letter

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

On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote: > On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote: > > On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote: > > > The inter-engine synchronisation (with and without semaphores) is > > > equally exercised by

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote: > > We need to formalize the process between i915 proper and GVT-g a bit > more, and address some of the current shortcomings and issues in the > process and GVT-g CI. > > This started off internally as a random list of items, I'm

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

On 20/10/2016 15:02, Chris Wilson wrote: On Thu, Oct 20, 2016 at 02:55:42PM +0100, Tvrtko Ursulin wrote: On 20/10/2016 10:16, Daniel Vetter wrote: On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote: On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote: On Wed, Oct 19,

[Intel-gfx] [PATCH 1/4] MAINTAINERS: Add "B:" for URI where to file bugs

Different subsystems and drivers have different preferences for where to file bugs and what information to include. Add "B:" entry for specifying the URI for the bug tracker directly, a web page for detailed info on filing bugs, or a mailto: URI. Cc: Daniel Vetter Cc: Joe

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] MAINTAINERS: Add "B:" for URI where to file bugs

== Series Details == Series: series starting with [1/4] MAINTAINERS: Add "B:" for URI where to file bugs URL : https://patchwork.freedesktop.org/series/14106/ State : warning == Summary == Series 14106v1 Series without cover letter

Re: [Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

On Thu, Oct 20, 2016 at 03:28:10PM +0300, Jani Nikula wrote: > On Thu, 20 Oct 2016, Nicolae Rosia wrote: > > Monitor hotplugging seems to be broken on latest 4.1/4.4 RT kernel with > > i915. > > I have tested this on non-RT kernel and it works. The answer to your

Re: [Intel-gfx] [PATCH] drm: Complete CEA modedb(VIC 1-107)

Hi Shashank, On 20-10-2016 11:25, Sharma, Shashank wrote: > Adding Jose and Daniel in cc. > > Regards > Shashank > -Original Message- > From: Sharma, Shashank > Sent: Thursday, October 20, 2016 3:58 PM > To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > Cc:

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

On 20/10/2016 10:16, Daniel Vetter wrote: On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote: On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote: On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote: The inter-engine synchronisation (with and without semaphores)

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

On Thu, Oct 20, 2016 at 02:55:42PM +0100, Tvrtko Ursulin wrote: > > On 20/10/2016 10:16, Daniel Vetter wrote: > >On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote: > >>On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote: > >>>On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris

Re: [Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

On Thu, 20 Oct 2016, David Weinehall wrote: > On Thu, Oct 20, 2016 at 03:28:10PM +0300, Jani Nikula wrote: >> On Thu, 20 Oct 2016, Nicolae Rosia wrote: >> > Monitor hotplugging seems to be broken on latest 4.1/4.4 RT kernel with >> > i915. >> > I

Re: [Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

Hi, On Thu, Oct 20, 2016 at 3:57 PM, David Weinehall wrote: >> > I get an udev event for unplugging, but there's no event generated for >> > plugging the monitor back in. >> >> Does it work on non-RT? Does it work on v4.8 or v4.9-rc1? > > The second one is relevant though. 4.1

Re: [Intel-gfx] [PATCH 39/41] drm/i915: Enable multiple timelines

On Thu, Oct 20, 2016 at 06:26:04PM +0300, Joonas Lahtinen wrote: > On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote: > > With the infrastructure converted over to tracking multiple timelines in > > the GEM API whilst preserving the efficiency of using a single execution > > timeline

Re: [Intel-gfx] [PATCH 15/41] drm/i915: Use a radixtree for random access to the object's backing storage

On 20/10/2016 16:03, Chris Wilson wrote: A while ago we switched from a contiguous array of pages into an sglist, for that was both more convenient for mapping to hardware and avoided the requirement for a vmalloc array of pages on every object. However, certain GEM API calls (like pwrite,

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

Em Qua, 2016-10-19 às 15:13 -0700, Matt Roper escreveu: > 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. > > > >

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

On ke, 2016-10-19 at 20:41 +0530, akash goel wrote: > 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: > > > @@ -34,11 +34,28 @@ struct shmem_sb_info { > > >   struct mempolicy *mpol; 

Re: [Intel-gfx] [PATCH 39/41] drm/i915: Enable multiple timelines

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote: > With the infrastructure converted over to tracking multiple timelines in > the GEM API whilst preserving the efficiency of using a single execution > timeline internally, we can now assign a separate timeline to every > context with

Re: [Intel-gfx] [PATCH 16/18] drm/i915: Enable multiple timelines

On to, 2016-10-20 at 13:49 +0100, Chris Wilson wrote: > On Mon, Sep 19, 2016 at 06:52:13PM +0300, Joonas Lahtinen wrote: > > > > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: > > > > > > @@ -315,17 +304,42 @@ submit_notify(struct i915_sw_fence *fence, enum > > > i915_sw_fence_notify

Re: [Intel-gfx] [PATCH 08/41] drm/i915: Remove superfluous wait_for_error() from throttle-ioctl

On to, 2016-10-20 at 16:03 +0100, Chris Wilson wrote: > Reviewed-by: Joonas Lahtinen " at the end of line. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915/lspcon: Add workaround for resuming in PCON mode

On my APL the LSPCON firmware resumes in PCON mode as opposed to the expected LS mode. It also appears to be in a state where AUX DPCD reads will succeed but return garbage recovering only after a few hundreds of milliseconds. After the recovery time DPCD reads will result in the correct values

[Intel-gfx] [PATCH 1/2] drm/i915/dp: Print full branch/sink descriptor for all outputs

Extend the branch/sink descriptor info with the missing device ID field and print this info for eDP and LSPCON connectors too. Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/intel_dp.c | 83 +++-- drivers/gpu/drm/i915/intel_drv.h|

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

Em Qui, 2016-10-20 às 15:18 -0200, Paulo Zanoni escreveu: > Em Qua, 2016-10-19 às 15:13 -0700, Matt Roper escreveu: > > > > 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 > > >

[Intel-gfx] [PATCH 23/41] drm/i915: Acquire the backing storage outside of struct_mutex in set-domain

As we can locklessly (well struct_mutex-lessly) acquire the backing storage, do so in set-domain-ioctl to reduce the contention on the struct_mutex. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH RESEND v2] drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7

Dropping WA because it was for early steppings. It is fixed in newer preproduction and all production revisions. v2: add references, updated commit message References: HSD#2126385, HSD#2131381, BSID#0764 Cc: Mika Kuoppala Cc: Chris Wilson Cc:

Re: [Intel-gfx] [PATCH 12/41] drm/i915: Introduce an internal allocator for disposable private objects

On 20/10/2016 16:03, Chris Wilson wrote: Quite a few of our objects used for internal hardware programming do not benefit from being swappable or from being zero initialised. As such they do not benefit from using a shmemfs backing storage and since they are internal and never directly exposed

[Intel-gfx] [PATCH 38/41] drm/i915: Defer setting of global seqno on request to submission

Defer the assignment of the global seqno on a request to its submission. In the next patch, we will only allocate the global seqno at that time, here we are just enabling the wait-for-submission before wait-for-seqno paths. Signed-off-by: Chris Wilson Reviewed-by:

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

On ke, 2016-10-19 at 17:35 +0100, Robert Bragg wrote: > I'll add a default: with MISSING_CASE as that looks like an i915- > specific convention; though it seems like a real shame to defer > missing case issues to runtime errors instead of taking advantage of > the compiler complaining at build

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

On Thu, Oct 20, 2016 at 05:29:36PM +0300, Mika Kuoppala wrote: > Arkadiusz Hiler writes: > > > When invalidating RCS TLB the device can enter RC6 state interrupting > > the process, therefore the need for render forcewake for the whole > > procedure. > > > > This WA is

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

Em Qua, 2016-10-19 às 15:13 -0700, Matt Roper escreveu: > 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. > >

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

On 19/10/2016 at 21:02:04 +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 prematurely. > >

[Intel-gfx] [PATCH 13/41] drm/i915: Reuse the active golden render state batch

The golden render state is constant, but we recreate the batch setting it up for every new context. If we keep that batch in a volatile cache we can safely reuse it whenever we need to initialise a new context. We mark the pages as purgeable and use the shrinker to recover pages from the batch

[Intel-gfx] [PATCH 22/41] drm/i915: Implement pwrite without struct-mutex

We only need struct_mutex within pwrite for a brief window where we need to serialise with rendering and control our cache domains. Elsewhere we can rely on the backing storage being pinned, and forgive userspace any races against us. Signed-off-by: Chris Wilson

  1   2   3   >