[Intel-gfx] Can Intel BDW GPU work perfectly with iommu enabled?

Hello, Found that there is a BDW GPU hang bug with iommu enabled in free desktop Bugzilla since two years ago, and it is still not closed: https://bugs.freedesktop.org/show_bug.cgi?id=89360 The last duplicated issue is 99964 which was reproduced with linux-4.10. Does anyone know if linux-4.11

Re: [Intel-gfx] [PATCH 12/13] drm/exynos: Remove custom FB helper deferred setup

2017년 07월 05일 00:18에 Daniel Vetter 이(가) 쓴 글: > From: Thierry Reding > > The FB helper core now supports deferred setup, so the driver's custom > implementation can be removed. Reviewed-by: Inki Dae Tested-by: Inki Dae Thanks,

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/cnl: Introduce initial Cannonlake Workarounds.

== Series Details == Series: series starting with [1/4] drm/i915/cnl: Introduce initial Cannonlake Workarounds. URL : https://patchwork.freedesktop.org/series/26881/ State : success == Summary == Series 26881v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for x86/gpu: CNL uses the same GMS values as SKL

== Series Details == Series: x86/gpu: CNL uses the same GMS values as SKL URL : https://patchwork.freedesktop.org/series/26880/ State : success == Summary == Series 26880v1 x86/gpu: CNL uses the same GMS values as SKL https://patchwork.freedesktop.org/api/1.0/series/26880/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm/i915: Disable per-engine reset for Broxton

On 04/07/17 09:09, Chris Wilson wrote: Triggering a GPU reset for one engine affects another, notably corrupting the context status buffer (CSB) effectively losing track of inflight requests. Adding a few printks: diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Add force wake for gen10+.

== Series Details == Series: drm/i915/cnl: Add force wake for gen10+. URL : https://patchwork.freedesktop.org/series/26879/ State : success == Summary == Series 26879v1 drm/i915/cnl: Add force wake for gen10+. https://patchwork.freedesktop.org/api/1.0/series/26879/revisions/1/mbox/ Test

[Intel-gfx] [PATCH 2/4] drm/i915/cnl: Add WaDisableReplayBufferBankArbitrationOptimization

WA to disable replay buffer destination buffer arbitration optimization. Same Wa on previous platforms has a different name: WaToEnableHwFixForPushConstHWBug Signed-off-by: Rodrigo Vivi Reviewed-by: Mika Kuoppala ---

[Intel-gfx] [PATCH 4/4] drm/i915/cnl: Apply large line width optimization

This bit enables hardware that will change the approximation used for distances calculations for AA wide lines so that they are rendered more accurately. The default value for this bit leaves the legacy behavior. There is no good reason to not enable the new approximation except if comparing to

[Intel-gfx] [PATCH 3/4] drm/i915/cnl: WaDisableEnhancedSBEVertexCaching

WA forTDS handle reallocation getting dropped by SDE, which may result in PS attribute corruption. Disable enhanced SBE vertex caching in COMMON_SLICE_CHICKEN2 offset. v2: Make it until B0 as spec tells. (by Mika). Signed-off-by: Rodrigo Vivi Reviewed-by: Mika Kuoppala

[Intel-gfx] [PATCH 1/4] drm/i915/cnl: Introduce initial Cannonlake Workarounds.

Let's inherit workarounds from previous platforms that according to wa_database and BSpec are still valid for Cannonlake. v2: Add missed workarounds. v3: Rebase v4: Remove bad chunk that was added to rc6 disable. (Ander) Also remove A0 W/a that are not needed anymore. v5: Rebase on top of

[Intel-gfx] [PATCH] x86/gpu: CNL uses the same GMS values as SKL

From: Paulo Zanoni So don't forget to reserve its stolen memory bits. v2: Add ack and remove "TODO" from commit message. Signed-off-by: Paulo Zanoni Signed-off-by: Rodrigo Vivi Acked-by: Thomas Gleixner

[Intel-gfx] [PATCH] drm/i915/cnl: Add force wake for gen10+.

By spec there is no change on force wake registers for Cannonlake. Let's reuse gen9 one. v2: Adding missing case for the write part. (Tvrtko) v3: Rebase on recent tree. v4: Make it for gen9+ instead adding gen10 only. (by Joonas). Cc: Tvrtko Ursulin Signed-off-by:

Re: [Intel-gfx] [PATCH] tools/null_state_gen: Add GEN10 golden context batch buffer creation

Hi Oscar, I had missed this patch here, but noticed now that I was refreshing and testing more cnl tests before re-submitting them. First of all I believe we need to remove the A0 w/a. I don't believe we will ever see one. So I'm removing all A0 exclusive W/a from the patches as well. I also

[Intel-gfx] ✓ Fi.CI.BAT: success for vfio: ABI for mdev display dma-buf operation (rev2)

== Series Details == Series: vfio: ABI for mdev display dma-buf operation (rev2) URL : https://patchwork.freedesktop.org/series/26786/ State : success == Summary == Series 26786v2 vfio: ABI for mdev display dma-buf operation

[Intel-gfx] [PATCH v10] 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.

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

v9->v10: 1) remove dma-buf management 2) refine the ABI API VFIO_DEVICE_QUERY_GFX_PLANE 3) track the dma-buf create and release in kernel mode v8->v9: 1) refine the dma-buf ioctl definition 2) add a lock to protect the dmabuf list 3) move drm format change to a separate patch 4) codes cleanup

Re: [Intel-gfx] [PATCH] intel/intel_chipset: Move IS_9XX below IS_GEN10.

Patch pushed to libdrm master. On Fri, Jun 30, 2017 at 2:28 PM, Rodrigo Vivi wrote: > No functional change. Just organizing the code > so it gets clear for future platforms. > > Paulo deserves credits becuase he was the one > that just noticed this IS_9XX was in the wrong

Re: [Intel-gfx] [PATCH i-g-t v3 4/4] chamelium: Dump obtained and reference frames to png on crc error

On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote: > When a CRC comparison error occurs, it is quite useful to get a dump > of both the frame obtained from the chamelium and the reference in > order > to compare them. > > This implements the frame dump, with a configurable path that

Re: [Intel-gfx] [PATCH 4/5] drm/i915/gen9+: Don't remove secondary power well requests

yep, makes total sense and you were right... no timeout.. Reviewed-by: Rodrigo Vivi On Fri, Jun 30, 2017 at 5:29 AM, Imre Deak wrote: > On Thu, Jun 29, 2017 at 01:06:01PM -0700, Rodrigo Vivi wrote: >> This patch makes sense and seems the right thing

Re: [Intel-gfx] [PATCH] drm: Remove unused drm_file parameter to drm_syncobj_replace_fence()

On Wed, Jul 5, 2017 at 1:12 PM, Chris Wilson wrote: > the drm_file parameter is unused, so remove it. > > Signed-off-by: Chris Wilson > Cc: Dave Airlie > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++ >

Re: [Intel-gfx] [PATCH i-g-t v3 3/4] lib/igt_chamelium: Add support for dumping chamelium frames to a png

On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote: > This introduces a chamelium_write_frame_to_png function that saves a > Chamelium frame dump to a png file. This should be useful when a > frame > comparison with a reference fails. > > Signed-off-by: Paul Kocialkowski

Re: [Intel-gfx] [PATCH i-g-t v3 2/4] tests/ chamelium: Remove the frame dump tests

NAK. You're right that these don't actually give us any advantage over just using CRCs and are just slower, however I left these tests in here moreso just so we had something to actually test the frame dumping functions so that we could avoid regressing them by accident since we're the only users

Re: [Intel-gfx] [PATCH i-g-t v3 1/4] chamelium: Calculate CRC from framebuffer instead of hardcoding it

On Wed, 2017-07-05 at 16:34 -0400, Lyude Paul wrote: > So a couple of notes here that will make it a lot easier for me to > review these in the future > >  * When you're doing a new revision of a patch series, it's helpful > to >    keep it in the same email thread as the original v1 so it's

Re: [Intel-gfx] [PATCH i-g-t v3 1/4] chamelium: Calculate CRC from framebuffer instead of hardcoding it

So a couple of notes here that will make it a lot easier for me to review these in the future * When you're doing a new revision of a patch series, it's helpful to keep it in the same email thread as the original v1 so it's easier to keep track of in people's mail clients (as well as

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Remove unused drm_file parameter to drm_syncobj_replace_fence()

== Series Details == Series: drm: Remove unused drm_file parameter to drm_syncobj_replace_fence() URL : https://patchwork.freedesktop.org/series/26868/ State : success == Summary == Series 26868v1 drm: Remove unused drm_file parameter to drm_syncobj_replace_fence()

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

On Wed, Jul 05, 2017 at 10:09:21AM +0200, Peter Rosin wrote: > On 2017-07-05 08:08, Daniel Vetter wrote: > > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote: > >> Hi! > >> > >> While trying to get CLUT support for the atmel_hlcdc driver, and > >> specifically for the emulated fbdev

Re: [Intel-gfx] [PATCH] drm: Remove pending_read_domains and pending_write_domain

On Wed, Jul 05, 2017 at 04:49:00PM +0100, Chris Wilson wrote: > The last user of these (i915.ko) no longer does. We can slim down the > core GEM object by removing the unused 8 bytes. > > Signed-off-by: Chris Wilson Time to celebrate! Applied, thanks. -Daniel > --- >

Re: [Intel-gfx] [PATCH 11/13] drm/i915: Protect against deferred fbdev setup

On Wed, Jul 05, 2017 at 12:08:15PM +0200, Maarten Lankhorst wrote: > Op 04-07-17 om 17:18 schreef Daniel Vetter: > > We could probably hit this already with our current async fbdev init, > > but it's much easier to hit this with the new deferred fbdev setup > > that I'm working on polishing. > > >

[Intel-gfx] [PATCH] drm: Remove unused drm_file parameter to drm_syncobj_replace_fence()

the drm_file parameter is unused, so remove it. Signed-off-by: Chris Wilson Cc: Dave Airlie --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++ drivers/gpu/drm/drm_syncobj.c | 8 +++- include/drm/drm_syncobj.h | 3 +--

Re: [Intel-gfx] [PATCH v4] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts

On Wed, Jul 05, 2017 at 06:25:30PM +, Navare, Manasi D wrote: > On Fri, Jun 30, 2017 at 09:33:48AM -0700, Manasi Navare wrote: > > This patch fixes the DP AUX CH timeouts observed during CI IGT tests > > thus fixing the CI failures. This is done by adding a quirk for a > > particular PCI

Re: [Intel-gfx] [PATCH v4] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts

On Fri, Jun 30, 2017 at 09:33:48AM -0700, Manasi Navare wrote: > This patch fixes the DP AUX CH timeouts observed during CI IGT tests > thus fixing the CI failures. This is done by adding a quirk for a > particular PCI device that requires the panel power cycle delay (T12) > to be set to 800ms

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

On 2017-07-05 08:08, Daniel Vetter wrote: > On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote: >> Hi! >> >> While trying to get CLUT support for the atmel_hlcdc driver, and >> specifically for the emulated fbdev interface, I received some >> push-back that my feeble in-driver attempts

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only free the oldest stale object before a fresh allocation

== Series Details == Series: drm/i915: Only free the oldest stale object before a fresh allocation URL : https://patchwork.freedesktop.org/series/26864/ State : success == Summary == Series 26864v1 drm/i915: Only free the oldest stale object before a fresh allocation

[Intel-gfx] [PATCH] drm/i915: Only free the oldest stale object before a fresh allocation

Inspired by Tvrtko's critique of the reaping of the stale contexts before allocating a new one, also limit the freed object reaping to the oldest stale object before allocating a fresh object. Unlike contexts, objects may have radically different sizes of backing storage, but similar to contexts,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Remove pending_read_domains and pending_write_domain

== Series Details == Series: drm: Remove pending_read_domains and pending_write_domain URL : https://patchwork.freedesktop.org/series/26860/ State : success == Summary == Series 26860v1 drm: Remove pending_read_domains and pending_write_domain

[Intel-gfx] [PATCH] drm: Remove pending_read_domains and pending_write_domain

The last user of these (i915.ko) no longer does. We can slim down the core GEM object by removing the unused 8 bytes. Signed-off-by: Chris Wilson --- include/drm/drm_gem.h | 15 --- 1 file changed, 15 deletions(-) diff --git a/include/drm/drm_gem.h

Re: [Intel-gfx] [PATCH 16/21] drm/i915/selftests: huge page tests

Quoting Matthew Auld (2017-07-03 15:14:58) > v2: mock test page support configurations and add MI_STORE_DWORD test > > v3: run all mockable huge page tests on all platforms via the mock_device Another thought is to have multiple objects in the ppgtt, to avoid any issues hidden by effectively

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Only free the oldest stale context before allocating

On 05/07/2017 15:26, Chris Wilson wrote: Currently, we move all unreferenced contexts to an RCU free list and then onto a worker for eventual reaping. To compensate against this growing into a long list with frequent allocations starving the system of available memory, before we allocate a new

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Drop request retirement before reaping stale contexts

On 05/07/2017 15:26, Chris Wilson wrote: Before we create a new context, we try and reap all the stale contexts (i.e. those that are freed but waiting for a worker to come and return their allocations to the system). Before we do this, we retire all requests so that we clear any inflight no

[Intel-gfx] ✓ Fi.CI.BAT: success for Fixed16.16 wrapper cleanup & wm optimization (rev4)

== Series Details == Series: Fixed16.16 wrapper cleanup & wm optimization (rev4) URL : https://patchwork.freedesktop.org/series/25692/ State : success == Summary == Series 25692v4 Fixed16.16 wrapper cleanup & wm optimization

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Check new context against kernel_context after reporting an error

== Series Details == Series: series starting with [1/4] drm/i915: Check new context against kernel_context after reporting an error URL : https://patchwork.freedesktop.org/series/26854/ State : success == Summary == Series 26854v1 Series without cover letter

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add option to support dynamic backlight via DPCD"

On Wed, Jul 05, 2017 at 01:03:46PM +0300, Jani Nikula wrote: > On Tue, 04 Jul 2017, David Weinehall wrote: > > This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3. > > > > The introduction of dynamic backlight control causes > > Lenovo ThinkPad X1 Carbon

[Intel-gfx] [PATCH 08/11] drm/i915/gen10: Calculate and enable transition WM

From: "Kumar, Mahesh" GEN > 9 require transition WM to be programmed if IPC is enabled. This patch calculates & enable transition WM for supported platforms. If transition WM is enabled, Plane read requests are sent at high priority until filling above the transition

[Intel-gfx] [PATCH 11/11] drm/i915/bxt: Enable IPC support

From: "Kumar, Mahesh" This patch adds IPC support for platforms. This patch enables IPC only for BXT/KBL platform as for SKL recommendation is to keep it disabled. IPC (Isochronous Priority Control) is the hardware feature, which dynamically controls the memory read

[Intel-gfx] [PATCH 10/11] drm/i915/cnl: Extend WM workaround with IPC for CNL

From: "Kumar, Mahesh" CNL:A & CNL:B have same workaround as KBL to increase wm level latency by 4us if IPC is enabled. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/intel_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

[Intel-gfx] [PATCH 09/11] drm/i915/glk: IPC linetime watermark workaround for GLK

From: "Kumar, Mahesh" IF IPC is enabled LINETIME_WM value should be half of calculated value line time = ROUNDDOWN(1/2 * Calculated Line Time) Earlier code was rounding-up the value, But updated Bspec says we should take the ROUNDDOWN. This patch corrects that as well.

[Intel-gfx] [PATCH 06/11] drm/i915/skl+: unify cpp value in WM calculation

From: "Kumar, Mahesh" use same cpp value in different phase of plane WM caluclation. Signed-off-by: Mahesh Kumar Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c | 6 ++ 1 file changed,

[Intel-gfx] [PATCH 05/11] drm/i915/skl+: WM calculation don't require height

From: "Kumar, Mahesh" height of plane was require to swap width/height in case of 90/270 rotation. Now src structure contains already swapped values, So we don't have to calculate height of the plane. Signed-off-by: Mahesh Kumar Reviewed-by:

[Intel-gfx] [PATCH 03/11] drm/i915: cleanup fixed-point wrappers naming

From: "Kumar, Mahesh" This patch make naming of fixed-point wrappers consistent operation__<1st operand>_<2nd operand> also shorten the name for fixed_16_16 to fixed16 s/u32_to_fixed_16_16/u32_to_fixed16 s/fixed_16_16_to_u32/fixed16_to_u32

[Intel-gfx] [PATCH 07/11] drm/i915/skl+: Optimize WM calculation

From: "Kumar, Mahesh" Plane configuration parameters doesn't change for each WM-level calculation. Currently we compute same parameters 8 times for each wm-level. This patch optimizes it by calculating these parameters in beginning & reuse during each level-wm

[Intel-gfx] [PATCH 04/11] drm/i915: Addition wrapper for fixed16.16 operation

From: "Kumar, Mahesh" This patch introduce addition wrapper for fixed point 16.16 operations. Which will be used by later patches to avoid direct member variables access of fixed_16_16_t structure. add_fixed16 : takes 2 fixed_16_16_t variable & returns fixed_16_16_t

[Intel-gfx] [PATCH 02/11] drm/i915: Always perform internal fixed16 division in 64 bits

From: "Kumar, Mahesh" This patch combines fixed_16_16_div & fixed_16_16_div_u64 wrappers. And new fixed_16_16_div wrapper always performs division operation in u64 internally, to avoid any data loss which was happening in earlier version of wrapper. earlier wrapper was

[Intel-gfx] [PATCH 00/11] Fixed16.16 wrapper cleanup & wm optimization

This series Include patches for: clean fixed16.16 naming & make them consistent optimize wm calculation code enable/Implement trans wm calculation Changes Since V1: - Split fixed16 cleanup code in more logical patches (Maarten) - make intel_compute_linetime_wm function

[Intel-gfx] [PATCH 01/11] drm/i915: take-out common clamping code of fixed16 wrappers

From: "Kumar, Mahesh" This patch creates a new function for clamping u64 to fixed16. And make use of this function in other fixed16 wrappers. Signed-off-by: Mahesh Kumar Reviewed-by: Maarten Lankhorst ---

[Intel-gfx] [PATCH 2/4] drm/i915: Move stale context reaping to common i915_gem_context_create

We need to reap the stale contexts for all new contexts, be they created by user in i915_gem_context_ioctl or from opening a new file in i915_gem_context_open. Both paths may be called very frequently accumulating many stale contexts before any worker has a chance to run and free their memory.

[Intel-gfx] [PATCH 3/4] drm/i915: Drop request retirement before reaping stale contexts

Before we create a new context, we try and reap all the stale contexts (i.e. those that are freed but waiting for a worker to come and return their allocations to the system). Before we do this, we retire all requests so that we clear any inflight no longer used contexts (who are only being kept

[Intel-gfx] [PATCH 4/4] drm/i915: Only free the oldest stale context before allocating

Currently, we move all unreferenced contexts to an RCU free list and then onto a worker for eventual reaping. To compensate against this growing into a long list with frequent allocations starving the system of available memory, before we allocate a new context we reap all the stale contexts. This

[Intel-gfx] [PATCH 1/4] drm/i915: Check new context against kernel_context after reporting an error

Avoid any pointer dereference in inspecting a potential PTR_ERR by checking for the error pointer before checking for an invalid context. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_context.c | 5

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move stale context reaping to common i915_gem_context_create

Quoting Tvrtko Ursulin (2017-07-05 14:50:57) > > On 05/07/2017 14:18, Chris Wilson wrote: > > We need to reap the stale contexts for all new contexts, be they created > > by user in i915_gem_context_ioctl or from opening a new file in > > i915_gem_context_open. Both paths may be called very

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Move stale context reaping to common i915_gem_context_create

On 05/07/2017 14:18, Chris Wilson wrote: We need to reap the stale contexts for all new contexts, be they created by user in i915_gem_context_ioctl or from opening a new file in i915_gem_context_open. Both paths may be called very frequently accumulating many stale contexts before any worker

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check new context against kernel_context after reporting an error

On 05/07/2017 14:18, Chris Wilson wrote: Avoid any pointer dereference in inspecting a potential PTR_ERR by checking for the error pointer before checking for an invalid context. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c | 5 ++--- 1

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Check new context against kernel_context after reporting an error

== Series Details == Series: series starting with [1/2] drm/i915: Check new context against kernel_context after reporting an error URL : https://patchwork.freedesktop.org/series/26851/ State : success == Summary == Series 26851v1 Series without cover letter

Re: [Intel-gfx] [RFC i-g-t 0/4] Redundant test pruning

On 27/06/2017 09:02, Tvrtko Ursulin wrote: On 26/06/2017 17:09, Daniel Vetter wrote: On Fri, Jun 23, 2017 at 12:31:39PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Small series which saves test execution time by removing the redundant tests. Tvrtko Ursulin

[Intel-gfx] [PATCH 2/2] drm/i915: Move stale context reaping to common i915_gem_context_create

We need to reap the stale contexts for all new contexts, be they created by user in i915_gem_context_ioctl or from opening a new file in i915_gem_context_open. Both paths may be called very frequently accumulating many stale contexts before any worker has a chance to run and free their memory.

[Intel-gfx] [PATCH 1/2] drm/i915: Check new context against kernel_context after reporting an error

Avoid any pointer dereference in inspecting a potential PTR_ERR by checking for the error pointer before checking for an invalid context. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Exercise independence of per-engine resets

== Series Details == Series: drm/i915/selftests: Exercise independence of per-engine resets URL : https://patchwork.freedesktop.org/series/26849/ State : success == Summary == Series 26849v1 drm/i915/selftests: Exercise independence of per-engine resets

Re: [Intel-gfx] [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

On Wed, Jul 05, 2017 at 11:46:14AM +0300, Laurent Pinchart wrote: > Hi Ville, > > On Tuesday 04 Jul 2017 15:44:02 Ville Syrjälä wrote: > > On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: > > > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > > >> From: Ville Syrjälä

[Intel-gfx] [PATCH] drm/i915/selftests: Exercise independence of per-engine resets

If all goes well, resetting one engine should not affect the operation of any others. So to test this, we setup a continuous stream of requests onto to each of the "innocent" engines whilst constantly resetting our target engine. Signed-off-by: Chris Wilson Cc: Mika

Re: [Intel-gfx] [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

On Wed, Jul 05, 2017 at 03:49:51PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 7/5/2017 3:46 PM, Ville Syrjälä wrote: > > On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 7/4/2017 9:26 PM, Ville Syrjälä wrote:

Re: [Intel-gfx] [PATCH 10/13] drm/fb-helper: Support deferred setup

Op 04-07-17 om 17:18 schreef Daniel Vetter: > FB helper code falls back to a 1024x768 mode if no outputs are connected > or don't report back any modes upon initialization. This can be annoying > because outputs that are added to FB helper later on can't be used with > FB helper if they don't

Re: [Intel-gfx] [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

Regards Shashank On 7/5/2017 3:46 PM, Ville Syrjälä wrote: On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote: Regards Shashank On 7/4/2017 9:26 PM, Ville Syrjälä wrote: On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote: YCBCR420 modes are supported only on

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Emit pipelined fence changes

On 03/07/2017 11:14, Chris Wilson wrote: Many years ago, long before requests, we tried doing this. We never quite got it right, but now with requests we have the tracking to do the job properly! Add a few words on the benefits in certain use cases/benchmarks. One of the stall points for

Re: [Intel-gfx] [PATCH v5 04/17] drm: add helper to validate ycbcr420 modes

On Wed, Jul 05, 2017 at 08:48:40AM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 7/4/2017 9:26 PM, Ville Syrjälä wrote: > > On Tue, Jul 04, 2017 at 07:41:51PM +0530, Shashank Sharma wrote: > >> YCBCR420 modes are supported only on HDMI 2.0 capable sources. > >> This patch adds

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/skl+: Check for supported plane configuration in Interlace mode

On Wed, Jul 05, 2017 at 12:09:19PM +0530, Mahesh Kumar wrote: > Hi, > > > On Tuesday 04 July 2017 08:11 PM, Ville Syrjälä wrote: > > On Mon, Jul 03, 2017 at 09:28:00PM +0530, Mahesh Kumar wrote: > >> Hi, > >> > >> > >> On Monday 03 July 2017 07:32 PM, Ville Syrjälä wrote: > >>> On Sat, Jul 01,

Re: [Intel-gfx] [PATCH 11/13] drm/i915: Protect against deferred fbdev setup

Op 04-07-17 om 17:18 schreef Daniel Vetter: > We could probably hit this already with our current async fbdev init, > but it's much easier to hit this with the new deferred fbdev setup > that I'm working on polishing. > > Cc: Maarten Lankhorst > Reported-by:

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add option to support dynamic backlight via DPCD"

On Tue, 04 Jul 2017, David Weinehall wrote: > This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3. > > The introduction of dynamic backlight control causes > Lenovo ThinkPad X1 Carbon 4th Gen to boot to a black screen; > presumably the backlight is off.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only skip updating execobject.offset after error

== Series Details == Series: drm/i915: Only skip updating execobject.offset after error URL : https://patchwork.freedesktop.org/series/26847/ State : success == Summary == Series 26847v1 drm/i915: Only skip updating execobject.offset after error

[Intel-gfx] [PATCH] drm/i915: Only skip updating execobject.offset after error

I was being overly paranoid in not updating the execobject.offset after performing the fallback copy where we set reloc.presumed_offset to -1. The thinking was to ensure that a subsequent NORELOC execbuf would be forced to process the invalid relocations. However this is overkill so long as we

Re: [Intel-gfx] [PATCH 2/2] drm/hdmi: Allow HDMI infoframe without VIC or S3D

Hi Ville, On Tuesday 04 Jul 2017 15:44:02 Ville Syrjälä wrote: > On Tue, Jul 04, 2017 at 01:56:07PM +0200, Andrzej Hajda wrote: > > On 03.07.2017 21:19, ville.syrj...@linux.intel.com wrote: > >> From: Ville Syrjälä > >> > >> Appedix F of HDMI 2.0 says that some

[Intel-gfx] [PATCH i-g-t v3 4/4] chamelium: Dump obtained and reference frames to png on crc error

When a CRC comparison error occurs, it is quite useful to get a dump of both the frame obtained from the chamelium and the reference in order to compare them. This implements the frame dump, with a configurable path that enables the use of this feature. Signed-off-by: Paul Kocialkowski

[Intel-gfx] [PATCH i-g-t v3 2/4] tests/ chamelium: Remove the frame dump tests

The frame dump tests provide no additional functionality over CRC tests and are considerably slower. Thus, these tests should be considered as poorer duplicates and removed. Signed-off-by: Paul Kocialkowski --- tests/chamelium.c | 53

[Intel-gfx] [PATCH i-g-t v3 3/4] lib/igt_chamelium: Add support for dumping chamelium frames to a png

This introduces a chamelium_write_frame_to_png function that saves a Chamelium frame dump to a png file. This should be useful when a frame comparison with a reference fails. Signed-off-by: Paul Kocialkowski --- lib/igt_chamelium.c | 40

[Intel-gfx] [PATCH i-g-t v3 1/4] chamelium: Calculate CRC from framebuffer instead of hardcoding it

This introduces CRC calculation for reference frames, instead of using hardcoded values for them. The rendering of reference frames may differ from machine to machine, especially due to font rendering, and the frame itself may change with subsequent IGT changes. These differences would cause the

Re: [Intel-gfx] [PATCH v5 09/17] drm: create hdmi output property

Regards Shashank On 7/5/2017 12:01 PM, Daniel Vetter wrote: On Wed, Jul 05, 2017 at 11:39:30AM +0530, Sharma, Shashank wrote: Regards Shashank On 7/4/2017 9:06 PM, Daniel Vetter wrote: On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote: HDMI displays can support various

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/skl+: Check for supported plane configuration in Interlace mode

Hi, On Tuesday 04 July 2017 08:11 PM, Ville Syrjälä wrote: On Mon, Jul 03, 2017 at 09:28:00PM +0530, Mahesh Kumar wrote: Hi, On Monday 03 July 2017 07:32 PM, Ville Syrjälä wrote: On Sat, Jul 01, 2017 at 09:35:12AM +0530, Mahesh Kumar wrote: Hi, On Friday 30 June 2017 05:56 PM, Ville

Re: [Intel-gfx] [PATCH v5 09/17] drm: create hdmi output property

On Wed, Jul 05, 2017 at 11:39:30AM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 7/4/2017 9:06 PM, Daniel Vetter wrote: > > On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote: > > > HDMI displays can support various output types, based on > > > the color space and

Re: [Intel-gfx] [PATCH v5 09/17] drm: create hdmi output property

Regards Shashank On 7/4/2017 9:06 PM, Daniel Vetter wrote: On Tue, Jul 04, 2017 at 07:41:56PM +0530, Shashank Sharma wrote: HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs from a HDMI 2.0 monitor could be: - RGB - YCBCR

Re: [Intel-gfx] [PATCH v3 00/16] improve the fb_setcmap helper

On Tue, Jul 04, 2017 at 12:36:56PM +0200, Peter Rosin wrote: > Hi! > > While trying to get CLUT support for the atmel_hlcdc driver, and > specifically for the emulated fbdev interface, I received some > push-back that my feeble in-driver attempts should be solved > by the core. This is my attempt