[Intel-gfx] [PATCH v2 08/10] drm/i915/gen9: Add skl_wm_level_equals()

Helper we're going to be using for implementing verification of the wm levels in skl_verify_wm_level(). Signed-off-by: Lyude Reviewed-by: Paulo Zanoni Cc: Maarten Lankhorst Cc: Ville Syrjälä

[Intel-gfx] [PATCH v3 01/10] drm/i915/skl: Move per-pipe ddb allocations into crtc states

First part of cleaning up all of the skl watermark code. This moves the structures for storing the ddb allocations of each pipe into intel_crtc_state, along with moving the structures for storing the current ddb allocations active on hardware into intel_crtc. Changes since v1: - Don't replace

[Intel-gfx] [PATCH v2 10/10] drm/i915/gen9: Don't wrap strings in verify_wm_state()

Wrapping strings is against the guidelines in Documentation/CodingStyle, chapter 2. Signed-off-by: Lyude Reviewed-by: Paulo Zanoni Cc: Maarten Lankhorst Cc: Ville Syrjälä Cc: Matt

[Intel-gfx] [PATCH v3 05/10] drm/i915/gen9: Get rid of redundant watermark values

Now that we've make skl_wm_levels make a little more sense, we can remove all of the redundant wm information. Up until now we'd been storing two copies of all of the skl watermarks: one being the skl_pipe_wm structs, the other being the global wm struct in drm_i915_private containing the raw

[Intel-gfx] [PATCH v3 06/10] drm/i915/gen9: Add ddb changes to atomic debug output

Finally, add some debugging output for ddb changes in the atomic debug output. This makes it a lot easier to spot bugs from incorrect ddb allocations. Signed-off-by: Lyude Reviewed-by: Maarten Lankhorst Reviewed-by: Paulo Zanoni

[Intel-gfx] [PATCH v2 09/10] drm/i915/gen9: Actually verify WM levels in verify_wm_state()

Thanks to Paulo Zanoni for indirectly pointing this out. Looks like we never actually added any code for checking whether or not we actually wrote watermark levels properly. Let's fix that. Changes since v1: - Use %u instead of %d when printing WM state mismatches Signed-off-by: Lyude

[Intel-gfx] [PATCH v3 03/10] drm/i915/gen9: Make skl_wm_level per-plane

Having skl_wm_level contain all of the watermarks for each plane is annoying since it prevents us from having any sort of object to represent a single watermark level, something we take advantage of in the next commit to cut down on all of the copy paste code in here. Changes since v1: - Style

[Intel-gfx] [PATCH v2 07/10] drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable

There's not much of a reason this should have the locations to read out the hardware state hardcoded, so allow the caller to specify the location and add this function to intel_drv.h. As well, we're going to need this function to be reusable for the next patch. Changes since v1: - Fix accidental

[Intel-gfx] [PATCH v3 00/10] Start of skl watermark cleanup

While it (mostly) works, the code for handling watermarks on Skylake has been kind of ugly for a while. As well a lot of it isn't that friendly to atomic transactions, Lots of copy paste, redundant wm values, etc. While this isn't a full cleanup, it's a good start. As well, we add a couple of

[Intel-gfx] [PATCH v2 04/10] drm/i915/gen9: Cleanup skl_pipe_wm_active_state

This function is a wreck, let's help it get its life back together and cleanup all of the copy pasta here. Signed-off-by: Lyude Reviewed-by: Maarten Lankhorst Reviewed-by: Paulo Zanoni Cc: Ville Syrjälä

[Intel-gfx] [PATCH v3 02/10] drm/i915/skl: Remove linetime from skl_wm_values

Next part of cleaning up the watermark code for skl. This is easy, since it seems that we never actually needed to keep track of the linetime in the skl_wm_values struct anyway. Signed-off-by: Lyude Reviewed-by: Paulo Zanoni Reviewed-by: Maarten

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: unconditionally apply the memory bandwidth WA

Reviewed-by: Lyude On Tue, 2016-10-11 at 15:25 -0300, Paulo Zanoni wrote: > Mahesh Kumar is already working on a proper implementation for the > workaround, but while we still don't have it, let's just > unconditionally apply the workaround for everybody and we hope we can >

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

On Fri, 2016-10-14 at 03:09 +, Yang, Libin wrote: > Tested-by: Libin Yang > > Regards, > Libin > > Thanks Libin. Can you confirm the max. BCLK frequency we set for the audio controller? -DK > > -Original Message- > > From: Intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

On Thu, 2016-10-13 at 21:44 +0300, Ville Syrjälä wrote: > On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote: > > According to BSpec, cdclk has to be not less than 432 MHz with DP audio > > enabled, port width x4, and link rate HBR2 (5.4 GHz) > > > > Having a lower cdclk triggers

Re: [Intel-gfx] [i-g-t PATCH] tests: prefix IGT kernel log messages with [IGT]

On Fri, 14 Oct 2016, Chris Wilson wrote: > On Fri, Oct 14, 2016 at 12:56:39PM +0300, Jani Nikula wrote: >> Make the IGT logging stand out better and easier to grep. > > [IGT] [igt] IGT igt i-g-t I-G-T [i-g-t] [I-G-T] > > Hobson's choice. Seems a sensible thing to do

[Intel-gfx] [PATCH v3 18/19] drm/i915: Make INTEL_GEN only take dev_priv

From: Tvrtko Ursulin Saves 968 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) v3: Rebase. Signed-off-by: Tvrtko Ursulin Reviewed-by: David Weinehall Acked-by: Daniel Vetter

[Intel-gfx] [ppping 1/2] intel: Export raw GEM mmap interfaces

Export a set of interfaces to allow the caller to have precise control over mapping the buffer - but still provide caching of the mmaps between callers. Signed-off-by: Chris Wilson --- intel/intel_bufmgr.h | 4 ++ intel/intel_bufmgr_gem.c | 154

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote: > While at it, make debugfs_path point at the debugfs root, not > dri. This'll be handy in future work. > > Signed-off-by: Jani Nikula > --- > tests/drm_lib.sh | 16 ++-- > 1 file changed, 10

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

Hi, This is first pull request to merge GVT-g device model in i915 which contains core GVT-g device model work to virtualize GPU resources. This tries to add feature of Intel GVT-g technology for full GPU virtualization. This version will support KVM based virtualization solution named as KVMGT.

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode URL : https://patchwork.freedesktop.org/series/13725/ State : warning == Summary == Series 13725v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode URL : https://patchwork.freedesktop.org/series/13767/ State : warning == Summary == Series 13767v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,01/19] drm/i915: Make HAS_DDI and HAS_PCH_LPT_LP only take dev_priv

== Series Details == Series: series starting with [CI,01/19] drm/i915: Make HAS_DDI and HAS_PCH_LPT_LP only take dev_priv URL : https://patchwork.freedesktop.org/series/13713/ State : failure == Summary == LD drivers/scsi/sd_mod.o LD drivers/scsi/built-in.o LD

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4)

On 10/13/2016 10:50 PM, Patchwork wrote: == Series Details == Series: drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4) URL : https://patchwork.freedesktop.org/series/13435/ State : warning == Summary == Series 13435v4 drm/i915: Allocate intel_engine_cs

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

On Thu, 13 Oct 2016, Chris Wilson wrote: > On Thu, Oct 13, 2016 at 04:55:49PM +0300, Jani Nikula wrote: >> For whatever reason, I got a machine here where that file is empty (not >> talking about the size, but cating the file actually produces >> nothing). And I've got

Re: [Intel-gfx] [PATCH] drm/edid: Only print the bad edid when aborting

On Fri, Oct 14, 2016 at 01:46:37PM +0300, Ville Syrjälä wrote: > On Thu, Oct 13, 2016 at 08:43:55PM +0100, Chris Wilson wrote: > > Currently, if drm.debug is enabled, we get a DRM_ERROR message on the > > intermediate edid reads. This causes transient failures in CI which > > flags up the sporadic

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4)

On 14/10/2016 10:02, Goel, Akash wrote: On 10/13/2016 10:50 PM, Patchwork wrote: == Series Details == Series: drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev4) URL : https://patchwork.freedesktop.org/series/13435/ State : warning == Summary == Series

[Intel-gfx] [i-g-t PATCH] tests: prefix IGT kernel log messages with [IGT]

Make the IGT logging stand out better and easier to grep. Signed-off-by: Jani Nikula --- lib/igt_core.c | 6 +++--- tests/drm_lib.sh | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/igt_core.c b/lib/igt_core.c index 43db4684cab0..9cd5f98d2014

Re: [Intel-gfx] [PATCH] drm/edid: Only print the bad edid when aborting

On Thu, Oct 13, 2016 at 08:43:55PM +0100, Chris Wilson wrote: > Currently, if drm.debug is enabled, we get a DRM_ERROR message on the > intermediate edid reads. This causes transient failures in CI which > flags up the sporadic EDID read failures, which are recovered by > rereading the EDID

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

On Thu, 13 Oct 2016, Dhinakaran Pandiyan wrote: > According to BSpec, cdclk has to be not less than 432 MHz with DP audio > enabled, port width x4, and link rate HBR2 (5.4 GHz) > > Having a lower cdclk triggers pipe underruns, which then lead to displays >

[Intel-gfx] [ppping 2/2] intel: Migrate handle/name lookups from linear lists to hashtables

Walking a linear list to find a matching PRIME handle or flinked name does not scale and becomes a major burden with just a few objects. That said, the fixed size hash is not much better, it just buckets the look into a few separate chains rather than one long one. References:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,01/19] drm/i915: Make HAS_DDI and HAS_PCH_LPT_LP only take dev_priv (rev2)

== Series Details == Series: series starting with [CI,01/19] drm/i915: Make HAS_DDI and HAS_PCH_LPT_LP only take dev_priv (rev2) URL : https://patchwork.freedesktop.org/series/13713/ State : success == Summary == Series 13713v2 Series without cover letter

Re: [Intel-gfx] [RFC PATCH v2 1/8] drm/i915: setup bridge for HDMI LPE audio driver

On Thu, Oct 13, 2016 at 02:38:30PM -0500, Pierre-Louis Bossart wrote: > Thanks Ville for the review. A lot of the comments are related to the > initial VED code we took pretty much as is, no issues to clean-up further. > > BTW, it looks like Jerome's patches were stuck for 10+ days on the >

[Intel-gfx] [PATCH v3 16/19] drm/i915: Make IS_CHERRYVIEW only take dev_priv

From: Tvrtko Ursulin Saves 864 bytes of .rodata strings and ~100 of .text. v2: Add parantheses around dev_priv. (Ville Syrjala) v3: Rebase. Signed-off-by: Tvrtko Ursulin Reviewed-by: David Weinehall

[Intel-gfx] [PATCH v5 5/5] drm/i915: Add lspcon resume function

As per the software design, we are driving lspcon in PCON mode. But while resuming from suspend, lspcon can go in LS mode (which is its default operating mode on power on) This patch adds a resume function for lspcon, which makes sure its operating in PCON mode, post resume. Signed-off-by:

[Intel-gfx] [PATCH v5 1/5] drm: Helper for lspcon in drm_dp_dual_mode

This patch adds lspcon support in dp_dual_mode helper. lspcon is essentially a dp->hdmi dongle with dual personality. LS mode: It works as a passive dongle, by level shifting DP++ signals to HDMI signals, in LS mode. PCON mode: It works as a protocol converter active dongle in pcon mode, by

[Intel-gfx] [PATCH v5 4/5] drm/i915: Enable lspcon initialization

This patch adds initialization code for lspcon. What we are doing here is: - Check if lspcon is configured in VBT for this port - If lspcon is configured, initialize it and configure it as DP port. V2: Addressed Ville's review comments: - Not adding AVI IF functions for

[Intel-gfx] [PATCH v5 2/5] drm/i915: Add lspcon support for I915 driver

This patch adds a new file, to accommodate lspcon support for I915 driver. These functions probe, detect, initialize and configure an on-board lspcon device during the driver init time. Also, this patch adds a small structure for lspcon device, which will provide the runtime status of the device.

[Intel-gfx] [PATCH v3 08/19] drm/i915: Make IS_IVYBRIDGE only take dev_priv

From: Tvrtko Ursulin Saves 848 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) v3: Rebase. Signed-off-by: Tvrtko Ursulin Reviewed-by: David Weinehall Acked-by: Daniel Vetter

[Intel-gfx] [PATCH v5 0/5] Enable lspcon support for GEN9 devices

LSPCON is essentially a dp++->hdmi adapter with dual mode of operation. These modes are: - Level Shifter mode: In LS mode, this device works as a type2 dp->hdmi passive dongle, which steps up DP++ output to appropriate HDMI 1.4 signal. This mode doesn't do any conversion at the protocol level. -

[Intel-gfx] [PATCH v5 3/5] drm/i915: Parse VBT data for lspcon

Many GEN9 boards come with on-board lspcon cards. Fot these boards, VBT configuration should properly point out if a particular port contains lspcon device, so that driver can initialize it properly. This patch adds a utility function, which checks the VBT flag for lspcon bit, and tells us if a

Re: [Intel-gfx] [PATCH 17/42] drm/i915: Pass around sg_table to get_pages/put_pages backend

[sending the draft reply until I get another look at it] On 07/10/2016 10:46, Chris Wilson wrote: The plan is to move obj->pages out from under the struct_mutex into its own per-object lock. We need to prune any assumption of the struct_mutex from the get_pages/put_pages backends, and to make

Re: [Intel-gfx] [PATCH 17/42] drm/i915: Pass around sg_table to get_pages/put_pages backend

On Fri, Oct 14, 2016 at 10:28:42AM +0100, Tvrtko Ursulin wrote: > diff --git a/drivers/gpu/drm/i915/i915_drv.h > b/drivers/gpu/drm/i915/i915_drv.h > index 3c22d49005fe..271e63c8f037 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2175,8 +2175,8 @@

Re: [Intel-gfx] [i-g-t PATCH] tests: prefix IGT kernel log messages with [IGT]

On Fri, Oct 14, 2016 at 12:56:39PM +0300, Jani Nikula wrote: > Make the IGT logging stand out better and easier to grep. [IGT] [igt] IGT igt i-g-t I-G-T [i-g-t] [I-G-T] Hobson's choice. Seems a sensible thing to do anyway. -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

Are the test run in the order defined by fast-feedback.testlist ? I intended the vgem unload test to be run as the first vgem testcase to minimise the chance of a stray module leak. Can we define the order within CI? Can we put comments into fast-feedback.testlist ? My understanding, yes, we

[Intel-gfx] [CI 2/3] drm/i915/gtt: Split gen8_ppgtt_clear_pte_range

Let's use more top-down approach, where each gen8_ppgtt_clear_* function is responsible for clearing the struct passed as an argument and calling relevant clear_range functions on lower-level tables. Doing this rather than operating on PTE ranges makes the implementation of shrinking page tables

[Intel-gfx] [CI 1/3] drm/i915: Remove unused "valid" parameter from pte_encode

We never used any invalid ptes, those were put in place for a possibility of doing gpu faults. However our batchbuffers are not restricted in length, so everything needs to be pointing to something and thus out-of-bounds is pointing to scratch. Remove the valid flag as it is always true. v2:

[Intel-gfx] [CI 3/3] drm/i915/gtt: Free unused lower-level page tables

Since "Dynamic page table allocations" were introduced, our page tables can grow (being dynamically allocated) with address space range usage. Unfortunately, their lifetime is bound to vm. This is not a huge problem when we're not using softpin - drm_mm is creating an upper bound on used range by

Re: [Intel-gfx] [PATCH 17/42] drm/i915: Pass around sg_table to get_pages/put_pages backend

On Fri, Oct 14, 2016 at 12:12:32PM +0300, Joonas Lahtinen wrote: > On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote: > > @@ -2376,6 +2374,19 @@ __deprecated > >  extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *); > >   > >  static inline bool > >

Re: [Intel-gfx] [RFC i-g-t PATCH 2/3] igt/gem_wait: Use new igt_dummyload api

On 10/13/2016 06:17 PM, Daniel Vetter wrote: > On Thu, Oct 13, 2016 at 10:49:39AM +0100, Chris Wilson wrote: >> On Thu, Oct 13, 2016 at 12:31:13PM +0300, Abdiel Janulgue wrote: >>> >>> >>> On 10/12/2016 03:07 PM, Chris Wilson wrote: On Wed, Oct 12, 2016 at 02:59:53PM +0300, Abdiel Janulgue

Re: [Intel-gfx] [PATCH 17/42] drm/i915: Pass around sg_table to get_pages/put_pages backend

On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote: > @@ -2376,6 +2374,19 @@ __deprecated >  extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *); >   >  static inline bool > +i915_gem_object_is_dead(const struct drm_i915_gem_object *obj) > +{ > + return

Re: [Intel-gfx] [PATCH v5 5/5] drm/i915: Add lspcon resume function

On pe, 2016-10-14 at 14:54 +0530, Shashank Sharma wrote: > As per the software design, we are driving lspcon in > PCON mode. But while resuming from suspend, lspcon can go > in LS mode (which is its default operating mode on power on) > > This patch adds a resume function for lspcon, which makes

Re: [Intel-gfx] [PATCH] drm: Print device information again in debugfs

On Thu, 13 Oct 2016, Daniel Vetter wrote: > I was a bit over-eager in my cleanup in > > commit 95c081c17f284de50eaca60d4d55643a64d39019 > Author: Daniel Vetter > Date: Tue Jun 21 10:54:12 2016 +0200 > > drm: Move master pointer from drm_minor

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Allocate intel_engine_cs structure only for the enabled engines (rev3)

On Fri, Oct 14, 2016 at 01:37:46PM +0300, Petri Latvala wrote: > > >>Are the test run in the order defined by fast-feedback.testlist ? > >>I intended the vgem unload test to be run as the first vgem testcase to > >>minimise the chance of a stray module leak. Can we define the order within > >>CI?

[Intel-gfx] [PATCH 1/1] drm/i915/guc: Sanitory checks for platform that dont have GuC

i915.enable_guc_loading/submission=2 forces the usage of GuC. For platforms that do not have a GuC, asking the kernel to use a GuC should not result in an error state. Do extra checks to see if the platform even has a GuC or not, regardless of the kernel parameter. v2: Based on Rodrigo's patch

[Intel-gfx] [PATCH 1/2] drm/i915/dmc: Make no_stepping_info an array

Make no_stepping_info an array of structs so that on plaforms that have only one binary of DMC, we can iterate through this array by having the same logic for firmware loads Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa ---

[Intel-gfx] [PATCH 2/2] drm/i915/DMC/KBL: Load DMC on KBL using he no_stepping_info array

Currently, for display there is only one DMC image for KBL. Remove the stepping_info table for KBL and use the no_stepping_info for loading the firmware image. Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa ---

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix mismatched INIT power domain disabling during suspend

== Series Details == Series: drm/i915: Fix mismatched INIT power domain disabling during suspend URL : https://patchwork.freedesktop.org/series/13723/ State : warning == Summary == Series 13723v1 drm/i915: Fix mismatched INIT power domain disabling during suspend

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,01/19] drm/i915: Make HAS_DDI and HAS_PCH_LPT_LP only take dev_priv (rev4)

== Series Details == Series: series starting with [CI,01/19] drm/i915: Make HAS_DDI and HAS_PCH_LPT_LP only take dev_priv (rev4) URL : https://patchwork.freedesktop.org/series/13713/ State : warning == Summary == Series 13713v4 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode

On Fri, Oct 14, 2016 at 11:01:11AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/3] drm/i915: Remove unused "valid" > parameter from pte_encode > URL : https://patchwork.freedesktop.org/series/13725/ > State : warning > > == Summary == > > Series

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode

On Fri, Oct 14, 2016 at 11:00:30AM +, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,1/3] drm/i915: Remove unused "valid" > parameter from pte_encode > URL : https://patchwork.freedesktop.org/series/13767/ > State : warning > > == Summary == > > Series

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

On Fri, 14 Oct 2016, Jani Nikula wrote: > On Fri, 14 Oct 2016, Petri Latvala wrote: >> On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote: >>> While at it, make debugfs_path point at the debugfs root, not >>> dri. This'll be handy in

[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev5)

== Series Details == Series: Enable lspcon support for GEN9 devices (rev5) URL : https://patchwork.freedesktop.org/series/8024/ State : failure == Summary == LD drivers/thermal/built-in.o LD drivers/iommu/built-in.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o In file

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

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

[Intel-gfx] [PATCH 09/41] drm/i915: Remove unused i915_gem_active_wait() in favour of _unlocked()

Since we only use the more generic unlocked variant, just rename it as the normal i915_gem_active_wait(). The temporary cost is that we need to always acquire the reference in a RCU safe manner, but the benefit is that we will combine the common paths. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 18/41] drm/i915: Move object backing storage manipulation to its own locking

Break the allocation of the backing storage away from struct_mutex into a per-object lock. This allows parallel page allocation, provided we can do so outside of struct_mutex (i.e. set-domain-ioctl, pwrite, GTT fault), i.e. before execbuf! The increased cost of the atomic counters are hidden

[Intel-gfx] [PATCH 04/41] drm/i915: Remove RPM sequence checking

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

[Intel-gfx] [PATCH 17/41] drm/i915: Pass around sg_table to get_pages/put_pages backend

The plan is to move obj->pages out from under the struct_mutex into its own per-object lock. We need to prune any assumption of the struct_mutex from the get_pages/put_pages backends, and to make it easier we pass around the sg_table to operate on rather than indirectly via the obj.

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

We will need to wait on DMA completion (as signaled via struct fence) before executing our i915_gem_request. Therefore we want to expose a method for adding the await on the fence itself to the request. v2: Add a comment detailing a failure to handle a signal-on-any fence-array. Signed-off-by:

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

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

[Intel-gfx] Fencing, fencing, fencing

Same old, same old, now with a new radixtree constructor and a sprinkling of r-b almost everywhere. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/41] drm/i915: Remove superfluous locking around userfault_list

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

[Intel-gfx] [PATCH 31/41] drm/i915: Introduce a global_seqno for each request

Though we will have multiple timelines, we still have a single timeline of execution. This we can use to provide an execution and retirement order of requests. This keeps tracking execution of requests simple, and vital for preserving a single waiter (i.e. so that we can order the waiters so that

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

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

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

A while ago we switched from a contiguous array of pages into an sglist, for that was both more convenient for mapping to hardware and avoided the requirement for a vmalloc array of pages on every object. However, certain GEM API calls (like pwrite, pread as well as performing relocations) do

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

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

[Intel-gfx] [PATCH 10/41] drm/i915: Defer active reference until required

We only need the active reference to keep the object alive after the handle has been deleted (so as to prevent a synchronous gem_close). Why then pay the price of a kref on every execbuf when we can insert that final active ref just in time for the handle deletion? Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 1/4] drm/i915: Adding intel_panel_scale_none() helper function

On 14.08.2015 08:18, Zhang, Xiong Y wrote: >> On Mon, Aug 10, 2015 at 06:23:19PM +, Rodrigo Vivi wrote: >>> I believe this function could be added along with the next patch that >>> is the first to use it... >>> Or it would be good to have a good commit message explaining why this >>> function

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev5)

On Fri, 14 Oct 2016, Patchwork wrote: > == Series Details == > > Series: Enable lspcon support for GEN9 devices (rev5) > URL : https://patchwork.freedesktop.org/series/8024/ > State : failure > > == Summary == > > LD drivers/thermal/built-in.o > LD

Re: [Intel-gfx] [PATCH v5 5/5] drm/i915: Add lspcon resume function

Regards Shashak On 10/14/2016 2:56 PM, Imre Deak wrote: On pe, 2016-10-14 at 14:54 +0530, Shashank Sharma wrote: As per the software design, we are driving lspcon in PCON mode. But while resuming from suspend, lspcon can go in LS mode (which is its default operating mode on power on) This

[Intel-gfx] [PATCH] drm/i915: Parse VBT data for lspcon

From: Shashank Sharma Many GEN9 boards come with on-board lspcon cards. Fot these boards, VBT configuration should properly point out if a particular port contains lspcon device, so that driver can initialize it properly. This patch adds a utility function, which

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev5)

I was about to send another series to address Imre's patches. There I have addressed this problems. Please wait for some time, I will re-sync and send V6 for all patches. Even though I am not sure why it dint apply on nightly, as I did a git-pull few hours ago. Regards Shashank

Re: [Intel-gfx] [RFC PATCH v2 1/8] drm/i915: setup bridge for HDMI LPE audio driver

On Fri, 14 Oct 2016, Ville Syrjälä wrote: > On Thu, Oct 13, 2016 at 02:38:30PM -0500, Pierre-Louis Bossart wrote: >> Thanks Ville for the review. A lot of the comments are related to the >> initial VED code we took pretty much as is, no issues to clean-up further.

[Intel-gfx] [PATCH] drm/i915: Fix cxsr_latency_table reorg

From: Tvrtko Ursulin I have re-ordered some struct members in patch: commit 44a655cae3043453f9dd8076538712d52e2e0ce4 Author: Tvrtko Ursulin Date: Thu Oct 13 11:09:23 2016 +0100 drm/i915: Shrink cxsr_latency_table but that

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

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

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

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

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

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

Re: [Intel-gfx] [i-g-t PATCH 1/3] tests: add more checks for finding the debugfs in script based tests

On Fri, 14 Oct 2016, Petri Latvala wrote: > On Thu, Oct 13, 2016 at 03:59:55PM +0300, Jani Nikula wrote: >> While at it, make debugfs_path point at the debugfs root, not >> dri. This'll be handy in future work. >> >> Signed-off-by: Jani Nikula >>

[Intel-gfx] [PATCH 27/41] drm/i915: Restore nonblocking awaits for modesetting

After combining the dma-buf reservation object and the GEM reservation object, we lost the ability to do a nonblocking wait on the i915 request (as we blocked upon the reservation object during prepare_fb). We can instead convert the reservation object into a fence upon which we can asynchronously

[Intel-gfx] [PATCH 19/41] drm/i915/dmabuf: Acquire the backing storage outside of struct_mutex

Use the per-object mm.lock to allocate the backing storage (and hold a reference to it across the dmabuf access) without resorting to struct_mutex. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH 29/41] drm/i915: Queue the idling context switch after all other timelines

Before suspend, we wait for the switch to the kernel context. In order for all the other context images to be complete upon suspend, that switch must be the last operation by the GPU (i.e. this idling request must not overtake any pending requests). To make this request execute last, we make it

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

With the infrastructure converted over to tracking multiple timelines in the GEM API whilst preserving the efficiency of using a single execution timeline internally, we can now assign a separate timeline to every context with full-ppgtt. Signed-off-by: Chris Wilson ---

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

Our low-level wait routine has evolved from our generic wait interface that handled unlocked, RPS boosting, waits with time tracking. If we push our GEM fence tracking to use reservation_objects (required for handling multiple timelines), we lose the ability to pass the required information down

[Intel-gfx] [PATCH 07/41] drm/i915: Allow i915_sw_fence_await_sw_fence() to allocate

In forthcoming patches, we want to be able to dynamically allocate the wait_queue_t used whilst awaiting. This is more convenient if we extend the i915_sw_fence_await_sw_fence() to perform the allocation for us if we pass in a gfp mask as an alternative than a preallocated struct. Signed-off-by:

[Intel-gfx] [PATCH 16/41] drm/i915: Refactor object page API

The plan is to make obtaining the backing storage for the object avoid struct_mutex (i.e. use its own locking). The first step is to update the API so that normal users only call pin/unpin whilst working on the backing storage. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH 26/41] drm: Add reference counting to drm_atomic_state

drm_atomic_state has a complicated single owner model that tracks the single reference from allocation through to destruction on another thread - or perhaps on a local error path. We can simplify this tracking by using reference counting (at a cost of a few more atomics). This is even more

[Intel-gfx] [PATCH 40/41] drm/i915: Enable userspace to opt-out of implicit fencing

Userspace is faced with a dilemma. The kernel requires implicit fencing to manage resource usage (we always must wait for the GPU to finish before releasing its PTE) and for third parties. However, userspace may wish to avoid this serialisation if it is either using explicit fencing between

[Intel-gfx] [PATCH 25/41] drm/i915: Move GEM activity tracking into a common struct reservation_object

In preparation to support many distinct timelines, we need to expand the activity tracking on the GEM object to handle more than just a request per engine. We already use the struct reservation_object on the dma-buf to handle many fence contexts, so integrating that into the GEM object itself is

[Intel-gfx] [PATCH 13/41] drm/i915: Markup GEM API with lockdep asserts

Add lockdep_assert_held(struct_mutex) to the API preamble of the internal GEM interfaces. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 21 +

[Intel-gfx] [PATCH 20/41] drm/i915: Implement pread without struct-mutex

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

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

We want to hide the latency of releasing objects and their backing storage from the submission, so we move the actual free to a worker. This allows us to switch to struct_mutex freeing of the object in the next patch. Furthermore, if we know that the object we are dereferencing remains valid for

  1   2   >