Re: [Intel-gfx] [PATCH 8/9] drm/mediatek: Use drm_plane_helper_check_state()

On Tue, 2016-07-26 at 19:07 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Replace the use of drm_plane_helper_check_update() with > drm_plane_helper_check_state() since we have a plane state. > > This also eliminates the double clipping the

Re: [Intel-gfx] [PATCH 8/9] drm/mediatek: Use drm_plane_helper_check_state()

On Tue, 2016-07-26 at 19:07 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Replace the use of drm_plane_helper_check_update() with > drm_plane_helper_check_state() since we have a plane state. > > This also eliminates the double clipping the

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: set proper N/M in modeset (rev2)

== Series Details == Series: drm/i915: set proper N/M in modeset (rev2) URL : https://patchwork.freedesktop.org/series/9857/ State : failure == Summary == Series 9857v2 drm/i915: set proper N/M in modeset http://patchwork.freedesktop.org/api/1.0/series/9857/revisions/2/mbox Test

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/16] drm/i915: Introduce i915_gem_active_wait_unlocked()

== Series Details == Series: series starting with [01/16] drm/i915: Introduce i915_gem_active_wait_unlocked() URL : https://patchwork.freedesktop.org/series/10469/ State : failure == Summary == Applying: drm/i915: Introduce i915_gem_active_wait_unlocked() Using index info to reconstruct a

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

From: Libin Yang When modeset occurs and the LS_CLK is set to some special values in DP mode, the N/M need to be set manually if audio is playing. The relationship of Maud and Naud is expressed in the following equation: Maud/Naud = 512 * fs / f_LS_Clk Please refer

[Intel-gfx] Disable power management on i915

Hello. I would like to know what is the best way to disable power management on the GPU unit, the purpose is to avoid GPU power transitions to avoid voltage swings. Additional information: Platform: Bay Trail J1900 O.S: Linux Kernel 4.4 Any help would be appreciated. Best Regards, Adolfo

Re: [Intel-gfx] [PATCH 05/16] drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex

On Mon, Aug 01, 2016 at 07:22:27PM +0100, Chris Wilson wrote: > The principal motivation for this was to try and eliminate the > struct_mutex from i915_gem_suspend - but we still need to hold the mutex > current for the i915_gem_context_lost(). (The issue there is that there > may be an indirect

Re: [Intel-gfx] [PATCH 4/4] drm/i915: pdev cleanup

On Mon, Aug 01, 2016 at 06:38:55PM +0300, David Weinehall wrote: > In an effort to simplify things for a future push of dev_priv instead > of dev wherever possible, always take pdev via dev_priv where > feasible, eliminating the direct access from dev. Right now this > only eliminates a few cases

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Consistent drm_minor use

On Mon, Aug 01, 2016 at 06:38:54PM +0300, David Weinehall wrote: > Use consistent naming for drm_minor, and always use kdev_to_drm_minor() > to convert kdev to drm_minor. > > Signed-off-by: David Weinehall I would have gone with struct drm_minor *minor, since

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/guc: symbolic names for GuC submission preferences

On 01/08/16 14:54, Jani Nikula wrote: On Fri, 22 Jul 2016, Dave Gordon wrote: The existing code that accesses the "enable_guc_submission" parameter uses explicit numerical values for the various possibilities, including in one case relying on boolean 0/1 mapping to

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Consistent struct device naming

On Mon, Aug 01, 2016 at 06:38:53PM +0300, David Weinehall wrote: > We currently have a mix of struct device *device, struct device *kdev, > and struct device *dev (the latter forcing us to refer to > struct drm_device as something else than the normal dev). > > To simplify things, always use kdev

[Intel-gfx] [PATCH 13/16] drm/i915: Remove pinned check from madvise ioctl

We don't need to incur the overhead of checking whether the object is pinned prior to changing its madvise. If the object is pinned, the madvise will not take effect until it is unpinned and so we cannot free the pages being pointed at by hardware. Marking a pinned object with allocated pages as

[Intel-gfx] [PATCH 15/16] drm/i915: Repack fence tiling mode and stride into a single integer

In the previous commit, we moved the obj->tiling_mode out of a bitfield and into its own integer so that we could safely use READ_ONCE(). Let us now repair some of that damage by sharing the tiling_mode with its companion, the fence stride. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 03/16] drm/i915: Convert non-blocking userptr waits for requests over to using RCU

We can completely avoid taking the struct_mutex around the non-blocking waits by switching over to the RCU request management (trading the mutex for a RCU read lock and some complex atomic operations). The improvement is that we gain further contention reduction, and overall the code become

[Intel-gfx] [PATCH 01/16] drm/i915: Introduce i915_gem_active_wait_unlocked()

It is useful to be able to wait on pending rendering without grabbing the struct_mutex. We can do this by using the i915_gem_active_get_rcu() primitive to acquire a reference to the pending request without requiring struct_mutex, just the RCU read lock, and then call i915_wait_request().

[Intel-gfx] [PATCH 04/16] drm/i915/userptr: Remove superfluous interruptible=false on waiting

Inside the kthread context, we can't be interrupted by signals so touching the mm.interruptible flag is pointless and wait-request now consumes EIO itself. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_userptr.c | 9 + 1 file changed, 1

[Intel-gfx] [PATCH 06/16] drm/gem/shrinker: Wait before acquiring struct_mutex under oom

We can now wait for the GPU (all engines) to become idle without requiring the struct_mutex. Inside the shrinker, we need to currently take the struct_mutex in order to purge objects and to purge the objects we need the GPU to be idle - causing a stall whilst we hold the struct_mutex. We can hide

[Intel-gfx] [PATCH 10/16] drm/i915: Remove (struct_mutex) locking for wait-ioctl

With a bit of care (and leniency) we can iterate over the object and wait for previous rendering to complete with judicial use of atomic reference counting. The ABI requires us to ensure that an active object is eventually flushed (like the busy-ioctl) which is guaranteed by our management of

[Intel-gfx] [PATCH 08/16] drm/i915: Remove unused no-shrinker-steal

After removing the user of this wart, we can remove the wart entirely. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_gem_shrinker.c | 3 --- 2 files changed, 4 deletions(-) diff --git

[Intel-gfx] [PATCH 09/16] drm/i915: Do a nonblocking wait first in pread/pwrite

If we try and read or write to an active request, we first must wait upon the GPU completing that request. Let's do that without holding the mutex (and so allow someone else to access the GPU whilst we wait). Upn completion, we will reacquire the mutex and only then start the operation (i.e. we do

[Intel-gfx] [PATCH 12/16] drm/i915: Reduce locking inside swfinish ioctl

We only need to take the struct_mutex if the object is pinned to the display engine and so requires checking for clflush. (The race with userspace pinning the object to a framebuffer is irrelevant.) v2: Use access once for compiler hints (or not as it is a bitfield) v3: READ_ONCE,

[Intel-gfx] [PATCH 14/16] drm/i915: Remove locking for get_tiling

Since we are not concerned with userspace racing itself with set-tiling (the order is indeterminant even if we take a lock), then we can safely read back the single obj->tiling_mode and do the static lookup of swizzle mode without having to take a lock. get-tiling is reasonably frequent due to

[Intel-gfx] [PATCH 07/16] drm/i915: Tidy generation of the GTT mmap offset

If we make the observation that mmap-offsets are only released when we free an object, we can then deduce that the shrinker only creates free space in the mmap arena indirectly by flushing the request list and freeing expired objects. If we combine this with the lockless vma-manager and lockless

[Intel-gfx] [PATCH 11/16] drm/i915: Remove (struct_mutex) locking for busy-ioctl

By applying the same logic as for wait-ioctl, we can query whether a request has completed without holding struct_mutex. The biggest impact system-wide is removing the flush_active and the contention that causes. Testcase: igt/gem_busy Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [PATCH 16/16] drm/i915: Assert that the request hasn't been retired

With all callers now not playing tricks with dropping the struct_mutex between waiting and retiring, we can assert that the request is ready to be retired. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 6 ++ 1 file changed, 2

[Intel-gfx] [PATCH 02/16] drm/i915: Convert non-blocking waits for requests over to using RCU

We can completely avoid taking the struct_mutex around the non-blocking waits by switching over to the RCU request management (trading the mutex for a RCU read lock and some complex atomic operations). The improvement is that we gain further contention reduction, and overall the code become

[Intel-gfx] [PATCH 05/16] drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex

The principal motivation for this was to try and eliminate the struct_mutex from i915_gem_suspend - but we still need to hold the mutex current for the i915_gem_context_lost(). (The issue there is that there may be an indirect lockdep cycle between cpu_hotplug (i.e. suspend) and struct_mutex via

[Intel-gfx] Put RCU request lookup to use

Having introduced a means for performing lockless request lookup, put it to use and implement lockless waiting and friends. The goal is to try and avoid holding onto the struct_mutex and avoid it entirely if possible as execbuf likes to hog it. -Chris

Re: [Intel-gfx] [PATCH v3] drm/i915/gen9: Update i915_drpc_info debugfs for coarse pg & forcewake info

Reviewed-by: Sagar Arun Kamble > On 6/27/2016 8:10 PM, akash.g...@intel.com wrote: From: Akash Goel Updated the i915_drpc_info debugfs with coarse power gating & forcewake info for Gen9. v2: Change all

[Intel-gfx] [PATCH v2] drm/i915: Unify request submission

Move request submission from emit_request into its own common vfunc from i915_add_request(). v2: Convert I915_DISPATCH_flags to BIT(x) whilst passing v3: Rename a few functions to match. v4: Reenable execlists submission after disabling guc. v5: Be aware that everyone calls

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

On Mon, Aug 01, 2016 at 05:28:34PM +0300, Joonas Lahtinen wrote: > On ma, 2016-08-01 at 11:15 +0100, Chris Wilson wrote: > > On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote: > > > > > > On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote: > > > > > > > > Space reservation is

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

On Mon, Aug 01, 2016 at 05:17:51PM +0100, Chris Wilson wrote: > Following that reasoning, if we just: > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index 15acaf6..d54c210 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

On Mon, Aug 01, 2016 at 05:28:34PM +0300, Joonas Lahtinen wrote: > On ma, 2016-08-01 at 11:15 +0100, Chris Wilson wrote: > > On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote: > > > > > > On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote: > > > > > > > > Space reservation is

[Intel-gfx] ✗ Ro.CI.BAT: failure for Various cleanup

== Series Details == Series: Various cleanup URL : https://patchwork.freedesktop.org/series/10458/ State : failure == Summary == Series 10458v1 Various cleanup http://patchwork.freedesktop.org/api/1.0/series/10458/revisions/1/mbox Test drv_module_reload_basic: pass ->

[Intel-gfx] [PATCH 4/4] drm/i915: pdev cleanup

In an effort to simplify things for a future push of dev_priv instead of dev wherever possible, always take pdev via dev_priv where feasible, eliminating the direct access from dev. Right now this only eliminates a few cases of dev, but it also obviates that we pass dev into a lot of functions

[Intel-gfx] [PATCH 2/4] drm/i915: Consistent struct device naming

We currently have a mix of struct device *device, struct device *kdev, and struct device *dev (the latter forcing us to refer to struct drm_device as something else than the normal dev). To simplify things, always use kdev when referring to struct device. Signed-off-by: David Weinehall

[Intel-gfx] [PATCH 1/4] drm/i915: Cosmetic fixes in i915_drv.h

Fix minor whitespace issues plus a typo. Signed-off-by: David Weinehall --- drivers/gpu/drm/i915/i915_drv.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index

[Intel-gfx] [PATCH 0/4] Various cleanup

To improve consistency in the driver, and to pave the way for further cleanup patches, do various bits of tidying. David Weinehall (4): drm/i915: Cosmetic fixes in i915_drv.h drm/i915: Consistent struct device naming drm/i915: Consistent drm_minor use drm/i915: pdev cleanup

[Intel-gfx] [PATCH 3/4] drm/i915: Consistent drm_minor use

Use consistent naming for drm_minor, and always use kdev_to_drm_minor() to convert kdev to drm_minor. Signed-off-by: David Weinehall --- drivers/gpu/drm/i915/i915_sysfs.c | 52 +++ 1 file changed, 26 insertions(+), 26

Re: [Intel-gfx] [PATCH 0/9] drm: Store clipped coordinates in drm_plane_state

On Mon, Aug 01, 2016 at 11:12:05AM -0400, Sean Paul wrote: > On Tue, Jul 26, 2016 at 12:06 PM, wrote: > > From: Ville Syrjälä > > > > Moving the clipped plane coordinates into drm_plane_state has been > > discussed a few times, but

Re: [Intel-gfx] [PATCH 0/9] drm: Store clipped coordinates in drm_plane_state

On Tue, Jul 26, 2016 at 12:06 PM, wrote: > From: Ville Syrjälä > > Moving the clipped plane coordinates into drm_plane_state has been > discussed a few times, but as no patches seems to have materialized, > I decoded to do it myself.

Re: [Intel-gfx] [PATCH 6/9] drm/rockchip: Use drm_plane_state.{src, dst}

On Tue, Jul 26, 2016 at 12:07 PM, wrote: > From: Ville Syrjälä > > Replace the private drm_rects in vop_plane_state with > the ones now living in drm_plane_state. > > Cc: Yao > Cc:

Re: [Intel-gfx] [PATCH 9/9] drm/simple_kms_helper: Use drm_plane_helper_check_state()

On Tue, Jul 26, 2016 at 12:07 PM, wrote: > From: Ville Syrjälä > > Replace the use of drm_plane_helper_check_update() with > drm_plane_helper_check_state() since we have a plane state. > > I don't see any actual users of

Re: [Intel-gfx] [PATCH 8/9] drm/mediatek: Use drm_plane_helper_check_state()

On Tue, Jul 26, 2016 at 12:07 PM, wrote: > From: Ville Syrjälä > > Replace the use of drm_plane_helper_check_update() with > drm_plane_helper_check_state() since we have a plane state. > > This also eliminates the double clipping the

Re: [Intel-gfx] [PATCH 7/9] drm/rockchip: Use drm_plane_helper_check_state()

On Tue, Jul 26, 2016 at 12:07 PM, wrote: > From: Ville Syrjälä > > Replace the use of drm_plane_helper_check_update() with > drm_plane_helper_check_state() since we have a plane state. > > Rockchip looks to handling plane clipping

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use drm_plane_helper_check_state()

On Tue, Jul 26, 2016 at 12:07 PM, wrote: > From: Ville Syrjälä > > Replace the use of drm_plane_helper_check_update() with > drm_plane_helper_check_state() since we have a plane state. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2 3/9] drm/plane-helper: Add drm_plane_helper_check_state()

On Tue, Jul 26, 2016 at 1:34 PM, wrote: > From: Ville Syrjälä > > Add a version of drm_plane_helper_check_update() which takes a plane > state instead of having the caller pass in everything. > > And to reduce code duplication, let's

Re: [Intel-gfx] [PATCH 4/9] drm/i915: Use drm_plane_state.{src, dst, visible}

On Tue, Jul 26, 2016 at 12:06 PM, wrote: > From: Ville Syrjälä > > Replace the private drm_rects/flags in intel_plane_state > with the ones now living in drm_plane_state. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 2/9] drm: Store clipped src/dst coordinatee in drm_plane_state

On Tue, Jul 26, 2016 at 12:06 PM, wrote: > From: Ville Syrjälä > > Pretty much all driver will have need for the clipped plane > coordinates, so let's stuff then into drm_plane_state. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915/debugfs: Take runtime_pm ref for sseu

On Mon, Aug 01, 2016 at 05:48:51PM +0300, Joonas Lahtinen wrote: > On ma, 2016-08-01 at 17:33 +0300, David Weinehall wrote: > > When reading the SSEU statistics, we need to call > > intel_runtime_pm_get() first, otherwise we might end up > > triggering "Device suspended during HW access". > > > >

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/debugfs: Take runtime_pm ref for sseu

== Series Details == Series: drm/i915/debugfs: Take runtime_pm ref for sseu URL : https://patchwork.freedesktop.org/series/10455/ State : failure == Summary == Series 10455v1 drm/i915/debugfs: Take runtime_pm ref for sseu http://patchwork.freedesktop.org/api/1.0/series/10455/revisions/1/mbox

Re: [Intel-gfx] [PATCH] drm/i915/debugfs: Take runtime_pm ref for sseu

On ma, 2016-08-01 at 17:33 +0300, David Weinehall wrote: > When reading the SSEU statistics, we need to call > intel_runtime_pm_get() first, otherwise we might end up > triggering "Device suspended during HW access". > > Signed-off-by: David Weinehall

[Intel-gfx] [PATCH] drm/i915/debugfs: Take runtime_pm ref for sseu

When reading the SSEU statistics, we need to call intel_runtime_pm_get() first, otherwise we might end up triggering "Device suspended during HW access". Signed-off-by: David Weinehall --- drivers/gpu/drm/i915/i915_debugfs.c | 9 - 1 file changed, 8

Re: [Intel-gfx] [PATCH 14/73] drm/i915: Unify request submission

On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote: > Move request submission from emit_request into its own common vfunc > from i915_add_request(). > > v2: Convert I915_DISPATCH_flags to BIT(x) whilst passing > v3: Rename a few functions to match. > v4: Reenable execlists submission after

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

On ma, 2016-08-01 at 11:15 +0100, Chris Wilson wrote: > On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote: > > > > On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote: > > > > > > Space reservation is already safe with respect to the ring->size > > > modulus, but hardware only

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/guc: symbolic names for GuC submission preferences

On Fri, 22 Jul 2016, Dave Gordon wrote: > The existing code that accesses the "enable_guc_submission" > parameter uses explicit numerical values for the various > possibilities, including in one case relying on boolean 0/1 > mapping to specific values (which could be

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Extract bdw_get_buf_trans_edp()

On ti, 2016-07-12 at 15:59 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make the BDW and SKL code a bit more similar by extracting the > low vswing handling for BDW into a helper, as we already have > it like that for SKL+. > > Cc: Mika

Re: [Intel-gfx] [Eaglelake][i915] pipe state doesn't match

On Fri, 15 Jul 2016, Felix Miata wrote: > I looked for a match on https://bugs.freedesktop.org/query.cgi but found > nothing looking like a close match that hadn't been marked fixed or > duplicate. So please file a new one? BR, Jani. > > This is happening on a Dell

Re: [Intel-gfx] [drm-intel-nightly] 2016y-07m-14d-21h-13m-02s UTC: locking dependency: drm_modeset_lock_all() || __blocking_notifier_call_chain

On Fri, 15 Jul 2016, Sedat Dilek wrote: > Hi, > > I see the below call-trace with latest d-i-n, guess latest linux-next FWIW, "d-i-n" is ambiguous (drm-intel-next vs. drm-intel-nightly) and we don't use that ourselves. BR, Jani. > will cause same issues. > ( Beyond

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

On Wed, 20 Jul 2016, "Vivi, Rodrigo" wrote: > We don't hardcode all userspace libraries in the userspace side for > the graphics stack and we do not validate all possible combinations of > libdrm, mesa, ddx, libva, etc... Why should we need this with > firmware? Because

Re: [Intel-gfx] [PATCH 00/23] drm/i915: Organize most GPU features by platform

On Wed, 20 Jul 2016, Carlos Santa wrote: > This patchset includes the following changes: > > - organize most GPU features so that they are easy to group by platforms. >It seems some of the ground work was already done for Gen7 features. >Reuse some of that work

Re: [Intel-gfx] [PATCH 13/23] drm/i915: Introduce GEN5_FEATURES for device info

On Wed, 20 Jul 2016, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. > > Use it for ilk. > > Signed-off-by: Carlos Santa > --- > drivers/gpu/drm/i915/i915_pci.c | 21 +++-- > 1 file changed, 11 insertions(+),

Re: [Intel-gfx] [PATCH 03/23] drm/i915: Move HAS_RUNTIME_PM definition to platform

On Wed, 20 Jul 2016, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > >

Re: [Intel-gfx] [PATCH 36/73] drm/i915: Refactor activity tracking for requests

On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote: > With the introduction of requests, we amplified the number of atomic > refcounted objects we use and update every execbuffer; from none to > several references, and a set of references that need to be changed. We > also introduced interesting

Re: [Intel-gfx] [PATCH i-g-t] tools/intel_reg: enable quiet option for mmio

On Wed, 20 Jul 2016, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > Skip decode options and formatting when the quiet option is used during > mmio reads. Makes intel_reg usable by scripts to return MMIO values. > > Signed-off-by: Clint Taylor

Re: [Intel-gfx] [PATCH 70/73] drm/i915: Move obj->active:5 to obj->flags

On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote: > We are motivated to avoid using a bitfield for obj->active for a couple > of reasons. Firstly, we wish to document our lockless read of obj->active > using READ_ONCE inside i915_gem_busy_ioctl() and that requires an > integral type (i.e. not

Re: [Intel-gfx] [PATCH 61/73] drm/i915: Record allocated vma size

On Mon, Aug 01, 2016 at 03:36:27PM +0300, Joonas Lahtinen wrote: > On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote: > > Tracking the size of the VMA as allocated allows us to dramatically > > reduce the complexity of later functions (like inserting the VMA in to > > the drm_mm range manager).

Re: [Intel-gfx] [PATCH 61/73] drm/i915: Record allocated vma size

On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote: > Tracking the size of the VMA as allocated allows us to dramatically > reduce the complexity of later functions (like inserting the VMA in to > the drm_mm range manager). > I assume this new revision only removed the extra hunk of code,

Re: [Intel-gfx] [PATCH 60/73] drm/i915: Update i915_gem_get_ggtt_size/_alignment to use drm_i915_private

On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote: > For consistency, internal functions should take drm_i915_private rather > than drm_device. Now that we are subclassing drm_device, there are no > more size wins, but being consistent is its own blessing. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 59/73] drm/i915: Update the GGTT size/alignment query functions

On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote: >   > -uint32_t > -i915_gem_get_gtt_size(struct drm_device *dev, uint32_t size, int tiling_mode) > +/** > + * i915_gem_get_ggtt_size - return required global GTT size for an object > + * @dev: drm device > + * @size: object size > + *

Re: [Intel-gfx] [PATCH 54/73] drm/i915: Fix up vma alignment to be u64

On ma, 2016-08-01 at 10:11 +0100, Chris Wilson wrote: > This is not the full fix, as we are required to percolate the u64 nature > down through the drm_mm stack, but this is required now to prevent > explosions due to mismatch between execbuf (eb_vma_misplaced) and vma > binding

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

== Series Details == Series: drm/i915: cleanup_plane_fb: also drop reference to current state wait_req URL : https://patchwork.freedesktop.org/series/10448/ State : failure == Summary == Applying: drm/i915: cleanup_plane_fb: also drop reference to current state wait_req Using index info to

[Intel-gfx] [PATCH] drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

There are two paths into intel_cleanup_plane_fb, the normal completion path and the failure path. In the failure case, intel_cleanup_plane_fb is called before drm_atomic_helper_swap_state, so any wait_req reference made in intel_prepare_plane_fb will be in old_intel_state->wait_req. In the

Re: [Intel-gfx] drm-intel.git Committers: Reminder about tagging bugfixes

On Thu, 14 Jul 2016, Daniel Vetter wrote: > Hi all, > > Apparently this wasn't known to everyone, hence this small reminder > about correctly tagging bugfixes when pushing them: > - add a Bugzilla: or References: link for any bug reported anywhere > (bugzilla or mailing

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

On Fri, Jul 29, 2016 at 01:41:26PM -0700, Matt Roper wrote: > On Fri, Jul 29, 2016 at 10:26:20PM +0300, Ville Syrjälä wrote: > > On Fri, Jul 29, 2016 at 02:48:09PM -0400, Lyude wrote: > > > So I've been working on trying to fix this entirely again (e.g. writing > > > the ddb properly), since from

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote: > Op 29-07-16 om 22:33 schreef Matt Roper: > > On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote: > >> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: > >>> This is completely untested (and probably horribly

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/73] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit

== Series Details == Series: series starting with [01/73] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit URL : https://patchwork.freedesktop.org/series/10444/ State : failure == Summary == Series 10444v1 Series without cover letter

Re: [Intel-gfx] [PATCH 46/73] drm/i915: Release vma when the handle is closed

On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote: > In order to prevent a leak of the vma on shared objects, we need to > hook into the object_close callback to destroy the vma on the object for > this file. However, if we destroyed that vma immediately we may cause > unexpected application

Re: [Intel-gfx] [I-G-T 2/3] igt/gem_mocs_settings: adding RC6 tests

On Mon, 1 Aug 2016, Chris Wilson wrote: On Mon, Aug 01, 2016 at 11:03:48AM +0100, Peter Antoine wrote: On Mon, 1 Aug 2016, Chris Wilson wrote: On Fri, Jul 29, 2016 at 10:34:35AM +0100, Peter Antoine wrote: This change adds a RC6 test for the MOCS. The MOCS registers are loaded and saved as

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote: > On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote: > > Space reservation is already safe with respect to the ring->size > > modulus, but hardware only expects to see values in the range > > 0...ring->size-1 (inclusive) and so

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

On Mon, Aug 01, 2016 at 01:07:55PM +0300, Joonas Lahtinen wrote: > On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote: > > Space reservation is already safe with respect to the ring->size > > modulus, but hardware only expects to see values in the range > > 0...ring->size-1 (inclusive) and so

Re: [Intel-gfx] [I-G-T 2/3] igt/gem_mocs_settings: adding RC6 tests

On Mon, Aug 01, 2016 at 11:03:48AM +0100, Peter Antoine wrote: > On Mon, 1 Aug 2016, Chris Wilson wrote: > > >On Fri, Jul 29, 2016 at 10:34:35AM +0100, Peter Antoine wrote: > >>This change adds a RC6 test for the MOCS. The MOCS registers are loaded > >>and saved as part of the RC6 cycle but not

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid

On Tue, Jul 12, 2016 at 02:39:47PM +0300, David Weinehall wrote: > On Thu, Jul 09, 2015 at 07:27:57PM +0200, Daniel Vetter wrote: > > On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote: > > > Adding this for SKL onwards. > > > > > > Signed-off-by: Sonika Jindal

Re: [Intel-gfx] [PATCH 13/73] drm/i915: Move the modulus for ring emission to the register write

On ma, 2016-08-01 at 10:10 +0100, Chris Wilson wrote: > Space reservation is already safe with respect to the ring->size > modulus, but hardware only expects to see values in the range > 0...ring->size-1 (inclusive) and so requires the modulus to prevent us > writing the value ring->size instead

Re: [Intel-gfx] [PATCH 07/12] drm/i915: Move DP link retraining into intel_dp_detect()

On Fri, Jul 29, 2016 at 02:45:29PM -0700, Manasi Navare wrote: > On Thu, Jul 28, 2016 at 05:36:14PM -0700, Manasi Navare wrote: > > On Thu, Jul 28, 2016 at 11:15:22PM +0300, Ville Syrjälä wrote: > > > On Thu, Jul 28, 2016 at 12:48:53PM -0700, Manasi Navare wrote: > > > > On Thu, Jul 28, 2016 at

Re: [Intel-gfx] [I-G-T 2/3] igt/gem_mocs_settings: adding RC6 tests

On Mon, 1 Aug 2016, Chris Wilson wrote: On Fri, Jul 29, 2016 at 10:34:35AM +0100, Peter Antoine wrote: This change adds a RC6 test for the MOCS. The MOCS registers are loaded and saved as part of the RC6 cycle but not all the registers are saved/restored. This tests that those registers are

Re: [Intel-gfx] [I-G-T 3/3] igt/gem_mocs_settings: Reduce the amount of cascading failures

On Mon, 1 Aug 2016, Chris Wilson wrote: On Fri, Jul 29, 2016 at 10:34:36AM +0100, Peter Antoine wrote: If one of the previous tests fails then the following tests fail. This patch means that the following tests do not fail when the previous test fails (for some cases). The problem is just

Re: [Intel-gfx] [PATCH 04/12] drm/i915: Reject mixing MST and SST/HDMI on the same digital port

Op 28-07-16 om 16:50 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > We can't mix MST with SST/HDMI on the same physical port, so we'll need > to reject such configurations in check_digital_port_conflicts(). Nothing > else will prevent this as MST

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Avoid mixing up SST and MST in DDI setup

Op 28-07-16 om 16:50 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > The MST vs. SST selection should depend purely on the choice of the > connector/encoder. So don't try to determine the correct DDI mode > based on the intel_dp->is_mst, which

Re: [Intel-gfx] [I-G-T 2/3] igt/gem_mocs_settings: adding RC6 tests

On Mon, 1 Aug 2016, Chris Wilson wrote: On Fri, Jul 29, 2016 at 10:34:35AM +0100, Peter Antoine wrote: This change adds a RC6 test for the MOCS. The MOCS registers are loaded and saved as part of the RC6 cycle but not all the registers are saved/restored. This tests that those registers are

[Intel-gfx] [PATCH 51/73] drm/i915: Double check the active status on the batch pool

We should not rely on obj->active being uptodate unless we manually flush it. Instead, we can verify that the next available batch object is idle by looking at its last active request (and checking it for completion). v2: remove the struct drm_device forward declaration added in the process of

[Intel-gfx] [PATCH 73/73] drm/i915: Export our request as a dma-buf fence on the reservation object

If the GEM objects being rendered with in this request have been exported via dma-buf to a third party, hook ourselves into the dma-buf reservation object so that the third party can serialise with our rendering via the dma-buf fences. Testcase: igt/prime_busy Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 45/73] drm/i915: Track active vma requests

Hook the vma itself into the i915_gem_request_retire() so that we can accurately track when a solitary vma is inactive (as opposed to having to wait for the entire object to be idle). This improves the interaction when using multiple contexts (with full-ppgtt) and eliminates some frequent list

[Intel-gfx] [PATCH 57/73] drm/i915: Split insertion/binding of an object into the VM

Split the insertion into the address space's range manager and binding of that object into the GTT to simplify the code flow when pinning a VMA. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH 49/73] drm/i915: Combine loops within i915_gem_evict_something

Slight micro-optimise to produce combine loops so that gcc is able to optimise the inner-loops concisely. Since we are reviewing the loops, we can update the comments to describe the current state of affairs, in particular the distinction between evicting from the global GTT (which may contain

[Intel-gfx] [PATCH 70/73] drm/i915: Move obj->active:5 to obj->flags

We are motivated to avoid using a bitfield for obj->active for a couple of reasons. Firstly, we wish to document our lockless read of obj->active using READ_ONCE inside i915_gem_busy_ioctl() and that requires an integral type (i.e. not a bitfield). Secondly, gcc produces abysmal code when

[Intel-gfx] [PATCH 61/73] drm/i915: Record allocated vma size

Tracking the size of the VMA as allocated allows us to dramatically reduce the complexity of later functions (like inserting the VMA in to the drm_mm range manager). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 103

[Intel-gfx] [PATCH 41/73] drm/i915: s/__i915_wait_request/i915_wait_request/

There is only one wait on request function now, so drop the "expert" indication of leading __. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 18 +-

[Intel-gfx] [PATCH 67/73] drm/i915: Make fb_tracking.lock a spinlock

We only need a very lightweight mechanism here as the locking is only used for co-ordinating a bitfield. v2: Move the cheap unlikely tests into the caller Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtien Cc: Daniel Vetter

[Intel-gfx] [PATCH 43/73] drm/i915: Move request list retirement to i915_gem_request.c

As the list retirement is now clean of implementation details, we can move it closer to the request management. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 44

  1   2   >