Re: [Intel-gfx] [PATCH 10/10] drm/i915/uc: Add params for specifying firmware

>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Arkadiusz Hiler >Sent: Tuesday, March 7, 2017 7:25 AM >To: intel-gfx@lists.freedesktop.org >Subject: [Intel-gfx] [PATCH 10/10] drm/i915/uc: Add params for specifying >firmware >

[Intel-gfx] linux-next: build failure after merge of the rcu tree

Hi Paul, After merging the rcu tree, today's linux-next build (x86_64 allmodconfig) failed like this: In file included from include/linux/resource_ext.h:19:0, from include/linux/pci.h:32, from include/drm/drmP.h:50, from

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915/glk: Apply cdclk workaround for DP audio

== Series Details == Series: series starting with [v2,1/2] drm/i915/glk: Apply cdclk workaround for DP audio URL : https://patchwork.freedesktop.org/series/20862/ State : success == Summary == Series 20862v1 Series without cover letter

[Intel-gfx] [PATCH v2 1/2] drm/i915/glk: Apply cdclk workaround for DP audio

Implement the DP-Audio cdclk restriction for GLK, similar to what is implemented for BDW and other GEN9 platforms. The max. pixel clock adjustment for GLK, however factors in the 2 pixels per clock output that GLK generates. Separating min. cdclk and max. pixel_rate would be nicer, but let's

[Intel-gfx] [PATCH v2 2/2] drm/i915: Implement cdclk restrictions based on Azalia BCLK

According to BSpec, "The CD clock frequency must be at least twice the frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by default. This check is needed because BXT and GLK support cdclk frequencies less than 192 MHz. Signed-off-by: Dhinakaran Pandiyan

Re: [Intel-gfx] [PATCH 06/10] drm/i915: Move cursor position and base handling into the platform specific functions

On Tue, Mar 07, 2017 at 05:27:05PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Supposedly on some platforms we can get extra atomicity guarantees for > CURPOS if we write it between the CURCNTR and CURBASE. Let's move the > CURPOS handling

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Clean up cursor junk from intel_crtc

On Tue, Mar 07, 2017 at 05:27:03PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move cursor_base, cursor_cntl, and cursor_size from intel_crtc > into intel_plane so that we don't need the crtc for cursor stuff > so much. > > Also entirely

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Support variable cursor height on ivb+

On Tue, Mar 07, 2017 at 05:27:09PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > IVB introduced the CUR_FBC_CTL register which allows reducing the cursor > height down to 8 lines from the otherwise square cursor dimensions. > Implement

Re: [Intel-gfx] [PATCH 09/10] drm/i915: Use fb->pitches[0] in cursor code

On Tue, Mar 07, 2017 at 05:27:08PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The cursor code currently ignores fb->pitches[0] (except when creating > the fb itself), and just uses the cursor_width*4 as the stride. Let's > make sure

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Split cursor check_plane into i845 and i9xx variants

On Tue, Mar 07, 2017 at 05:27:07PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The 845/865 and 830/855/9xx+ style cursor don't have that > much in common with each other, so let's just split the > .check_plane() hook into two variants as

Re: [Intel-gfx] [PATCH 07/10] drm/i915: Drop useless posting reads from cursor commit

On Tue, Mar 07, 2017 at 05:27:06PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > There should be no need to do posting reads between all the cursor > register accessess. Let's just drop them. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Refactor CURBASE calculation

On Tue, Mar 07, 2017 at 05:27:02PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The remaining cursor base address calculations are spread > around into several different locations. Just pull it all > into one place. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Parametrize cursor/primary pipe select bits

On Tue, Mar 07, 2017 at 05:27:00PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Pass intel_plane and intel_crtc to plane hooks

On Tue, Mar 07, 2017 at 05:27:01PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Streamline things by passing intel_plane and intel_crtc instead of > the drm types to our plane hooks. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 05/10] drm/i915: Refactor CURPOS calculation

On Tue, Mar 07, 2017 at 05:27:04PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Move the CURPOS calculations to seprate function. This will allow > sharing the code between the 845/865 vs. others codepaths when we > otherwise split them

Re: [Intel-gfx] linux-next: build failure after merge of the sunxi tree

Hi Stephen, Daniel, On Tue, Mar 07, 2017 at 11:10:19AM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the sunxi tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > drivers/gpu/drm/sun4i/sun4i_crtc.c: In function 'sun4i_crtc_enable_vblank': >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/userptr: Deactivate a failed userptr if the worker reports an EFAULT

== Series Details == Series: series starting with [v2,1/3] drm/i915/userptr: Deactivate a failed userptr if the worker reports an EFAULT URL : https://patchwork.freedesktop.org/series/20855/ State : success == Summary == Series 20855v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3] drm/i915: Store a permanent error in obj->mm.pages

On Tue, Mar 07, 2017 at 07:47:29PM +0200, Joonas Lahtinen wrote: > On ti, 2017-03-07 at 13:20 +, Chris Wilson wrote: > > Once the object has been truncated, it is unrecoverable. To facilitate > > detection of this state store the error in obj->mm.pages. > > > > This is required for the next

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Nuke debug messages from the pipe update critical section

== Series Details == Series: drm/i915: Nuke debug messages from the pipe update critical section URL : https://patchwork.freedesktop.org/series/20853/ State : success == Summary == Series 20853v1 drm/i915: Nuke debug messages from the pipe update critical section

[Intel-gfx] [PATCH v2 3/3] drm/i915/userptr: Disallow wrapping GTT into a userptr

If we allow the user to convert a GTT mmap address into a userptr, we may end up in recursion hell, where currently we hit a mutex deadlock but other possibilities include use-after-free during the unbind/cancel_userptr. [ 143.203989] gem_userptr_bli D0 902898 0x [ 143.204054]

[Intel-gfx] [PATCH v2 2/3] drm/i915/userptr: Only flush the workqueue if required

To avoid waiting for work from other invalidate-range threads where not required, only wait on the userptr cancel workqueue if we have added some work to it. Signed-off-by: Chris Wilson Cc: Michał Winiarski Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH v2 1/3] drm/i915/userptr: Deactivate a failed userptr if the worker reports an EFAULT

If the worker fails, it no longer has pages to release and can be immediately removed from the invalidate-tree. Signed-off-by: Chris Wilson Cc: Michał Winiarski Cc: Tvrtko Ursulin ---

[Intel-gfx] [PATCH] drm/i915: Nuke debug messages from the pipe update critical section

From: Ville Syrjälä printks are slow so we should not be doing them from the vblank evade critical section. These could explain why we sometimes seem to blow past our 100 usec deadline. The problem has been there ever since commit bfd16b2a23dc ("drm/i915: Make

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: CCS prep stuff

On Tue, Mar 07, 2017 at 08:22:03PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: CCS prep stuff > URL : https://patchwork.freedesktop.org/series/20851/ > State : warning > > == Summary == > > Series 20851v1 drm/i915: CCS prep stuff >

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: CCS prep stuff

== Series Details == Series: drm/i915: CCS prep stuff URL : https://patchwork.freedesktop.org/series/20851/ State : warning == Summary == Series 20851v1 drm/i915: CCS prep stuff https://patchwork.freedesktop.org/api/1.0/series/20851/revisions/1/mbox/ Test gem_exec_flush: Subgroup

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Read link status more times when EQ not done

On Thu, 02 Mar 2017, "Lee, Shawn C" wrote: > From: "Lee, Shawn C" > > Display driver read DPCD register 0x202, 0x203 and 0x204 to identify > eDP sink status.If PSR exit is ongoing at eDP sink, and eDP source > read these registers at the same time.

[Intel-gfx] [PATCH v2 5/5] drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages

From: Ville Syrjälä DRM_UT_CORE generates way too much noise usually, so having the framebuffer init failures use DRM_UT_CORE is a pain when trying to find out the reason why you failed in creating a framebuffer. Let's use DRM_UT_KMS for these debug messages

[Intel-gfx] [PATCH 4/5] drm/i915: Pass the correct plane index to _intel_compute_tile_offset()

From: Ville Syrjälä intel_fill_fb_info() should pass the correct plane index to _intel_compute_tile_offset() once we start to care about the AUX surface. Signed-off-by: Ville Syrjälä Reviewed-by: Imre Deak ---

[Intel-gfx] [PATCH 2/5] drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()

From: Ville Syrjälä Let's try to keep the alignment requirements in one place, and so towards that end let's move the AUX_DIST alignment handling into intel_surf_alignment() alongside the main surface alignment stuff. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 3/5] drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane

From: Ville Syrjälä To make life easier let's allow skl_plane_stride() to be called for the AUX surface even when there is no AUX surface. Avoids special cases in the callers. Signed-off-by: Ville Syrjälä Reviewed-by: Imre Deak

[Intel-gfx] [PATCH 0/5] drm/i915: CCS prep stuff

From: Ville Syrjälä Already reviewed prep stuff for CCS. Posting it separately so that I can push it if/when CI gives the green light. Ville Syrjälä (5): drm/i915: Plumb drm_framebuffer into more places drm/i915: Move nv12 chroma plane handling into

[Intel-gfx] [PATCH 1/5] drm/i915: Plumb drm_framebuffer into more places

From: Ville Syrjälä Now that framebuffers can be used even before calling drm_framebuffer_init() we can start to plumb them into more places, instead of passing individual pieces for fb metadata. Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH v3] drm/i915: Store a permanent error in obj->mm.pages

On ti, 2017-03-07 at 13:20 +, Chris Wilson wrote: > Once the object has been truncated, it is unrecoverable. To facilitate > detection of this state store the error in obj->mm.pages. > > This is required for the next patch which should be applied to v4.10 > (via stable), so we also need to

Re: [Intel-gfx] [PATCH] drm/i915: Clear the VBT defaults for unused ports

On Fri, 03 Mar 2017, Ville Syrjälä wrote: > On Fri, Mar 03, 2017 at 05:01:42AM -0800, Manasi Navare wrote: >> If during VBT parsing we find that the port is unused, >> the driver code just bails out without clearing the >> defaults for that port. This can cause

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Flush idle work when changing missed-irq fault injection (rev3)

== Series Details == Series: drm/i915: Flush idle work when changing missed-irq fault injection (rev3) URL : https://patchwork.freedesktop.org/series/20752/ State : failure == Summary == Series 20752v3 drm/i915: Flush idle work when changing missed-irq fault injection

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Cursor code cleanup and cursor "FBC" support for IVB+

== Series Details == Series: drm/i915: Cursor code cleanup and cursor "FBC" support for IVB+ URL : https://patchwork.freedesktop.org/series/20835/ State : success == Summary == Series 20835v1 drm/i915: Cursor code cleanup and cursor "FBC" support for IVB+

Re: [Intel-gfx] [PATCH v2] drm/i915: suppress atomic commit error message under gvt-g env

On Tue, Mar 07, 2017 at 12:46:35PM -0500, bing@intel.com wrote: > From: Bing Niu > > under virtualization enviroment, it is possible guest update pipe > registers across vblank intervals due to overhead of mmio traps or vm > schedule out. However, it is safe since those

Re: [Intel-gfx] [PATCH i-g-t] tests: Add gem_spin_batch

On Tue, Mar 07, 2017 at 06:02:29PM +0200, Mika Kuoppala wrote: > Add gem_spin_batch to test that the dummyload infra > is working properly. Can be also act as tool to force > a single engine to be busy for controlled period of time. > > v2: plenty of igt-fu improvements (Chris) > > Cc: Abdiel

[Intel-gfx] [PATCH i-g-t] tests: Add gem_spin_batch

Add gem_spin_batch to test that the dummyload infra is working properly. Can be also act as tool to force a single engine to be busy for controlled period of time. v2: plenty of igt-fu improvements (Chris) Cc: Abdiel Janulgue Cc: Chris Wilson

[Intel-gfx] [CI] drm/i915: Flush idle work when changing missed-irq fault injection

In order for the missed-irq update to take effect, the device must be idle. So when the user updates the fault injection via debugfs, idle the device. v2: Idle is explicitly required for setting test_irq, and good behaviour for clearing the missed_irq. v3: Use matching types; expanding to more

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_gt: Remove duplicated PARAM_NO_ERROR_CAPTURE define

Added r-b and applied upstream. On 2017-03-06 05:10 PM, Michel Thierry wrote: LOCAL_CONTEXT_PARAM_NO_ERROR_CAPTURE exists in lib/ioctl_wrappers.h since commit 171b21d9f761 ("igt/gem_ctx_param: Update invalid parma number"). Cc: Chris Wilson Signed-off-by: Michel

[Intel-gfx] ✓ Fi.CI.BAT: success for GuC Scrub vol. 1 (rev10)

== Series Details == Series: GuC Scrub vol. 1 (rev10) URL : https://patchwork.freedesktop.org/series/16856/ State : success == Summary == Series 16856v10 GuC Scrub vol. 1 https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/10/mbox/ Test kms_pipe_crc_basic: Subgroup

[Intel-gfx] [PATCH 06/10] drm/i915: Move cursor position and base handling into the platform specific functions

From: Ville Syrjälä Supposedly on some platforms we can get extra atomicity guarantees for CURPOS if we write it between the CURCNTR and CURBASE. Let's move the CURPOS handling into the platform specific hooks to make the possible without having to pass the

[Intel-gfx] [PATCH 08/10] drm/i915: Split cursor check_plane into i845 and i9xx variants

From: Ville Syrjälä The 845/865 and 830/855/9xx+ style cursor don't have that much in common with each other, so let's just split the .check_plane() hook into two variants as well. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 02/10] drm/i915/huc: Add huc_to_i915

Used to obtain "dev_priv" from huc struct pointer. We already have similar thing for guc. Cc: Michal Wajdeczko Signed-off-by: Arkadiusz Hiler Reviewed-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH 09/10] drm/i915: Use fb->pitches[0] in cursor code

From: Ville Syrjälä The cursor code currently ignores fb->pitches[0] (except when creating the fb itself), and just uses the cursor_width*4 as the stride. Let's make sure fb->pitches[0] actually matches what we expect it to be. We can also relax the stride vs.

[Intel-gfx] [PATCH 04/10] drm/i915: Clean up cursor junk from intel_crtc

From: Ville Syrjälä Move cursor_base, cursor_cntl, and cursor_size from intel_crtc into intel_plane so that we don't need the crtc for cursor stuff so much. Also entirely nuke cursor_addr which IMO doesn't provide any benefit since it's not actually used by the

[Intel-gfx] [PATCH 00/10] drm/i915: Cursor code cleanup and cursor "FBC" support for IVB+

From: Ville Syrjälä Here's a pile of cleanups to the cursor code. I think it makes the code quite a bit more pleasant to look at. I wrote most of these probably one or two years ago, so I figured it's about time I try to get them in. I've also included support

[Intel-gfx] [PATCH 07/10] drm/i915: Drop useless posting reads from cursor commit

From: Ville Syrjälä There should be no need to do posting reads between all the cursor register accessess. Let's just drop them. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 32

[Intel-gfx] [PATCH 05/10] drm/i915: Refactor CURPOS calculation

From: Ville Syrjälä Move the CURPOS calculations to seprate function. This will allow sharing the code between the 845/865 vs. others codepaths when we otherwise split them apart. Signed-off-by: Ville Syrjälä ---

[Intel-gfx] [PATCH 10/10] drm/i915: Support variable cursor height on ivb+

From: Ville Syrjälä IVB introduced the CUR_FBC_CTL register which allows reducing the cursor height down to 8 lines from the otherwise square cursor dimensions. Implement support for it. CUR_FBC_CTL can't be used when the cursor is rotated. Commandeer the

[Intel-gfx] [PATCH 01/10] drm/i915: Parametrize cursor/primary pipe select bits

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 7 ++- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git

[Intel-gfx] [PATCH 02/10] drm/i915: Pass intel_plane and intel_crtc to plane hooks

From: Ville Syrjälä Streamline things by passing intel_plane and intel_crtc instead of the drm types to our plane hooks. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_atomic_plane.c | 6 +-

[Intel-gfx] [PATCH 03/10] drm/i915: Refactor CURBASE calculation

From: Ville Syrjälä The remaining cursor base address calculations are spread around into several different locations. Just pull it all into one place. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 54

[Intel-gfx] [PATCH 10/10] drm/i915/uc: Add params for specifying firmware

`guc_firmware_path` and `huc_firmware_path` module parameters are added. Using the parameter disables version checks and loads desired firmware instead of the default one. v2: make params unsafe && notice about disabled fw check (J. Lahtinen) Cc: Chris Wilson Cc:

[Intel-gfx] [PATCH 07/10] drm/i915/guc: Simplify intel_guc_init_hw()

Current version of intel_guc_init_hw() does a lot: - cares about submission - loads huc - implement WA This change offloads some of the logic to intel_uc_init_hw(), which now cares about the above. v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko) v3: rename once again v4:

[Intel-gfx] [PATCH 03/10] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()

GuC historically has two "startup" functions called _init() and _setup() Then HuC came with it's _init() and _load(). This commit renames intel_guc_setup() and intel_huc_load() to *uc_init_hw() as they called from the i915_gem_init_hw(). The aim is to be consistent in that entry points called

[Intel-gfx] [PATCH 08/10] drm/i915/uc: Simplify firmware path handling

Currently fw->path values can represent one of three possible states: 1) NULL - device without the uC 2) '\0' - device with the uC but have no firmware 3) else - device with the uC and we have firmware Second case is used only to WARN at a later stage. We can WARN right away and merge cases

[Intel-gfx] [PATCH 09/10] drm/i915/uc: Separate firmware selection and preparation

intel_{h,g}uc_init_fw selects correct firmware and then triggers it's preparation (fetch + initial parsing). This change separates out select steps, so those can be called by the sanitize_options(). Then, during the init_fw(), we prepare the firmware if the firmware was selected. Cc: Michal

[Intel-gfx] [PATCH 06/10] drm/i915/guc: Extract param logic form guc_init_fw()

Let intel_guc_init_fw() focus on determining and fetching the correct firmware. This patch introduces intel_uc_sanitize_options() that is called from intel_sanitize_options(). Then, if we have GuC, we can call intel_guc_init_fw() conditionally and we do not have to do the internal checks. v2:

[Intel-gfx] [PATCH 05/10] drm/i915/uc: Introduce intel_uc_init_fw()

Instead of calling intel_guc_init() and intel_huc_init() one by one this patch introduces intel_uc_init_fw() function that calls them both. Called functions are renamed accordingly. Trying to have subject_verb_object ordering and more descriptive names, the intel_huc_init() and intel_guc_init()

[Intel-gfx] [PATCH 04/10] drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c

The file fits better. Additionally rename it to intel_uc_prepare_fw(), as the function does more than simple fetch. `obj` cleanup in the function is also fixed (i.e. removed). In the fail scenario it was always 'put' but there's no possible flow that initializes the obj properly and then goes to

[Intel-gfx] [PATCH v7 00/10] GuC Scrub vol. 1

Reasoning = General GuC/HuC cleanup simplifying logic and moving chunks around as the area got pretty rusty. This is the first part of effort to clean it up. A lot of logic were extracted from intel_guc_load() to other functions - it did not only handle the actual loading but had WA

[Intel-gfx] [PATCH 01/10] drm/i915/uc: Drop superfluous externs in intel_uc.h

Externs are implicit and we generally try to avoid them. Cc: Michal Wajdeczko Signed-off-by: Arkadiusz Hiler Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uc.h | 12 ++-- 1 file

Re: [Intel-gfx] [PATCH 4/4] drm/i915/guc: Break out the GuC log "extras"

On Fri, Feb 24, 2017 at 06:01:37AM -0800, Oscar Mateo wrote: > When initializing the GuC log struct, there is an object we need to > allocate always, since the GuC needs its address at fw load time. > The rest are "extras", in the sense that we only need them if we > actually enable GuC logging.

Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: s/ads_vma/addon

On Fri, Feb 24, 2017 at 06:01:36AM -0800, Oscar Mateo wrote: > This vma contains much more than just the additional data struct (ads) > and since we were already using the word "addon" as an object in > guc_addon_create, make it the preffered one. No need for the vma suffix > either, as that

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3] drm/i915: Store a permanent error in obj->mm.pages (rev2)

== Series Details == Series: series starting with [v3] drm/i915: Store a permanent error in obj->mm.pages (rev2) URL : https://patchwork.freedesktop.org/series/20829/ State : success == Summary == Series 20829v2 Series without cover letter

Re: [Intel-gfx] [PATCH 04/15] drm/i915: add page_size_mask to dev_info

On Mon, Mar 06, 2017 at 11:54:03PM +, Matthew Auld wrote: > Signed-off-by: Matthew Auld > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_gem_gtt.h | 14 ++ > drivers/gpu/drm/i915/i915_pci.c | 23 ++- >

Re: [Intel-gfx] [PATCH 0/7] drm/i915/dsi: stop using drm_panel, refactor

On Mon, 06 Mar 2017, Jani Nikula wrote: > This is pretty natural continuation to what Hans started. We haven't > made use of the drm_panel framework much at all, and there's no need in > sight, really. It was good for ensuring a certain amount of separation > between the

Re: [Intel-gfx] Implementing Miracast

On 07/03/17 05:00, Daniel Kasak wrote: Any news on this? I'm also interested :) Dan Hmm, good question! I will ping internally and see if we are ready to release something as an RFC. Martin ___ Intel-gfx mailing list

[Intel-gfx] [PATCH v3] drm/i915: Store a permanent error in obj->mm.pages

Once the object has been truncated, it is unrecoverable. To facilitate detection of this state store the error in obj->mm.pages. This is required for the next patch which should be applied to v4.10 (via stable), so we also need to mark this patch for backporting. In that regard, let's consider

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: Store a permanent error in obj->mm.pages

On Tue, Mar 07, 2017 at 01:12:42PM +, Chris Wilson wrote: > On Tue, Mar 07, 2017 at 12:57:19PM -, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [v2,1/2] drm/i915: Store a permanent error in > > obj->mm.pages > > URL :

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: Store a permanent error in obj->mm.pages

On Tue, Mar 07, 2017 at 12:57:19PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/2] drm/i915: Store a permanent error in > obj->mm.pages > URL : https://patchwork.freedesktop.org/series/20829/ > State : failure > > == Summary == > > Series 20829v1

Re: [Intel-gfx] [PATCH] drm/i915: Avoid clearing the base drm_crtc_state

On Mon, Mar 06, 2017 at 09:05:47PM +, Chris Wilson wrote: > On Mon, Mar 06, 2017 at 06:46:16PM +0100, Daniel Vetter wrote: > > On Fri, Mar 03, 2017 at 03:46:44PM +, Chris Wilson wrote: > > > @@ -11289,9 +11287,9 @@ clear_intel_crtc_state(struct intel_crtc_state > > > *crtc_state) > > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: Store a permanent error in obj->mm.pages

== Series Details == Series: series starting with [v2,1/2] drm/i915: Store a permanent error in obj->mm.pages URL : https://patchwork.freedesktop.org/series/20829/ State : failure == Summary == Series 20829v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Avoid clearing the base drm_crtc_state

On Mon, Mar 06, 2017 at 06:46:16PM +0100, Daniel Vetter wrote: > On Fri, Mar 03, 2017 at 03:46:44PM +, Chris Wilson wrote: > > To prevent having to preserve the drm_crtc_state as we clear the > > intel_crtc_state, only memset our extended state. > > > > Fixes: > >

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Use formalized struct definition for ads object

On Tue, Mar 07, 2017 at 11:09:36AM +, Michal Wajdeczko wrote: > Manual pointer manipulation is error prone. Let compiler calculate > right offsets for us in case we need to change ads layout. > > v2: don't call it object (Chris) > > Signed-off-by: Michal Wajdeczko

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Use formalized struct definition for ads object (rev2)

== Series Details == Series: drm/i915/guc: Use formalized struct definition for ads object (rev2) URL : https://patchwork.freedesktop.org/series/20826/ State : success == Summary == Series 20826v2 drm/i915/guc: Use formalized struct definition for ads object

[Intel-gfx] [PATCH v2 2/2] drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl

Before we instantiate/pin the backing store for our use, we can prepopulate the shmemfs filp efficiently using a write into the pagecache. We avoid the penalty of instantiating all the pages, important if the user is just writing to a few and never uses the object on the GPU, and using a direct

[Intel-gfx] [PATCH v2 1/2] drm/i915: Store a permanent error in obj->mm.pages

Once the object has been truncated, it is unrecoverable. To facilitate detection of this state store the error in obj->mm.pages. This is required for the next patch which should be applied to v4.10 (via stable), so we also need to mark this patch for backporting. In that regard, let's consider

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl

On Tue, Mar 07, 2017 at 01:46:36PM +0200, Petri Latvala wrote: > On Tue, Mar 07, 2017 at 10:22:09AM +, Chris Wilson wrote: > > > igt@gem_madvise@dontneed-before-exec: pass -> {'fail', 'incomplete'} > > That test is expected to fail, that it ever passed is a fluke. > > That subtest should be

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl

On Tue, Mar 07, 2017 at 10:22:09AM +, Chris Wilson wrote: > > igt@gem_madvise@dontneed-before-exec: pass -> {'fail', 'incomplete'} > That test is expected to fail, that it ever passed is a fluke. That subtest should be removed from IGT then? > incomplete there should be a failure in the

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Disallow wrapping GTT into a userptr

On Tue, Mar 07, 2017 at 11:18:53AM +, Chris Wilson wrote: > Simplest patch is then fun with obj->userptr.work, i.e. something like > if (xchg(>userptr.work, NULL)) return 0; Overly simplistic. Too many holes to plug between potential users of the pages and the current cancel_userptr.

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Disallow wrapping GTT into a userptr

On Tue, Mar 07, 2017 at 11:03:03AM +, Tvrtko Ursulin wrote: > > On 07/03/2017 09:13, Chris Wilson wrote: > >On Tue, Mar 07, 2017 at 08:42:26AM +, Tvrtko Ursulin wrote: > >> > >>On 06/03/2017 15:36, Chris Wilson wrote: > >>>If we allow the user to convert a GTT mmap address into a userptr,

[Intel-gfx] [PATCH v2] drm/i915/guc: Use formalized struct definition for ads object

Manual pointer manipulation is error prone. Let compiler calculate right offsets for us in case we need to change ads layout. v2: don't call it object (Chris) Signed-off-by: Michal Wajdeczko Cc: Oscar Mateo Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Disallow wrapping GTT into a userptr

On 07/03/2017 09:13, Chris Wilson wrote: On Tue, Mar 07, 2017 at 08:42:26AM +, Tvrtko Ursulin wrote: On 06/03/2017 15:36, Chris Wilson wrote: If we allow the user to convert a GTT mmap address into a userptr, we may end up in recursion hell, where currently we hit a mutex deadlock but

Re: [Intel-gfx] [PATCH i-g-t v2] lib: Define a common bit operations library

On Thu, Mar 02, 2017 at 11:46:11AM -0800, Michel Thierry wrote: > > On 01/03/17 23:45, Daniel Vetter wrote: > > On Wed, Mar 01, 2017 at 04:14:31PM +, Chris Wilson wrote: > > > On Wed, Mar 01, 2017 at 07:52:26AM -0800, Michel Thierry wrote: > > > > Bring the test/set/clear bit functions we

Re: [Intel-gfx] [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

On Tue, Mar 07, 2017 at 12:48:26PM +0200, Andy Shevchenko wrote: > On Sun, 2017-02-26 at 22:45 +0100, Daniel Vetter wrote: > > On Tue, Feb 21, 2017 at 06:52:24PM +0200, Andy Shevchenko wrote: > > > On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote: > > > > On Tue, 21 Feb 2017, Andy Shevchenko

Re: [Intel-gfx] [PATCH v1] drm/i915/bxt: use NULL for GPIO connection ID

On Sun, 2017-02-26 at 22:45 +0100, Daniel Vetter wrote: > On Tue, Feb 21, 2017 at 06:52:24PM +0200, Andy Shevchenko wrote: > > On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote: > > > On Tue, 21 Feb 2017, Andy Shevchenko > > l.co > > > m> wrote: > > > > The

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/guc: Use formalized struct definition for ads object

== Series Details == Series: drm/i915/guc: Use formalized struct definition for ads object URL : https://patchwork.freedesktop.org/series/20826/ State : warning == Summary == Series 20826v1 drm/i915/guc: Use formalized struct definition for ads object

Re: [Intel-gfx] [PATCH] drm/i915/guc: Use formalized struct definition for ads object

On Tue, Mar 07, 2017 at 10:39:46AM +, Chris Wilson wrote: > On Tue, Mar 07, 2017 at 10:29:35AM +, Michal Wajdeczko wrote: > > Manual pointer manipulation is error prone. Let compiler calculate > > right offsets for us in case we need to change ads layout. > > > > Signed-off-by: Michal

Re: [Intel-gfx] [PATCH] drm/i915/guc: Use formalized struct definition for ads object

On Tue, Mar 07, 2017 at 10:29:35AM +, Michal Wajdeczko wrote: > Manual pointer manipulation is error prone. Let compiler calculate > right offsets for us in case we need to change ads layout. > > Signed-off-by: Michal Wajdeczko > Cc: Oscar Mateo

[Intel-gfx] [PATCH] drm/i915/guc: Use formalized struct definition for ads object

Manual pointer manipulation is error prone. Let compiler calculate right offsets for us in case we need to change ads layout. Signed-off-by: Michal Wajdeczko Cc: Oscar Mateo Cc: Joonas Lahtinen Cc: Daniele

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl

On Tue, Mar 07, 2017 at 11:55:20AM +0200, Petri Latvala wrote: > > For the record, manually launched extended test run on SKL > resulted in: > > commit f88cf1067cc499f4c9236c4e3ff7e410f9cc76d7 > Author: Chris Wilson > Date: Sat Mar 4 10:35:32 2017 + > >

Re: [Intel-gfx] [PATCH 2/4] lib/scatterlist: Avoid potential scatterlist entry overflow

Hi David, Chris noticed your "scatterlist: don't overflow length field" patch and pinged me, so I am copying you on another thread which tries to solve the same problem. My latest series is here: https://patchwork.freedesktop.org/series/18062/, but it has been going from some time

Re: [Intel-gfx] [PATCH v7 5/6] drm/i915: enable scrambling

On Fri, 2017-03-03 at 21:58 +0530, Shashank Sharma wrote: > Geminilake platform sports a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the monitor

Re: [Intel-gfx] [PATCH 03/15] drm/i915/selftests: exercise cache domain eviction

On Mon, Mar 06, 2017 at 11:54:02PM +, Matthew Auld wrote: Add a selftest to exercise evicting neighbouring nodes that conflict due to page colouring in the GTT. > v2: add a peppering of comments > > Signed-off-by: Matthew Auld > Cc: Chris Wilson

Re: [Intel-gfx] [PATCH 02/15] drm/i915: use correct node for handling cache domain eviction

On Mon, Mar 06, 2017 at 11:54:01PM +, Matthew Auld wrote: > It looks like we were incorrectly comparing vma->node against itself > instead of the target node, when evicting for a node on systems where we > need guard pages between regions with different cache domains. As a > consequence we can

Re: [Intel-gfx] [RFC PATCH 00/15] drm/i915: initial support for huge gtt pages

On Mon, Mar 06, 2017 at 11:53:59PM +, Matthew Auld wrote: > This series adds support for huge-pages for the gtt, where "huge" > is 64K, 2M and 1G. This isn't everything I have and there are still some > things which I have yet to implement, like handling evict-for-node with the > 64K/4K

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl

For the record, manually launched extended test run on SKL resulted in: commit f88cf1067cc499f4c9236c4e3ff7e410f9cc76d7 Author: Chris Wilson Date: Sat Mar 4 10:35:32 2017 + drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl

  1   2   >