[Intel-gfx] [PATCH v2 33/40] drm: Optimise power-of-two alignments in drm_mm_scan_add_block()

For power-of-two alignments, we can avoid the 64bit divide and do a simple bitwise add instead. v2: s/alignment_mask/remainder_mask/ Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/drm_mm.c | 9 -

[Intel-gfx] [PATCH v2 40/40] drm: kselftest for drm_mm and bottom-up allocation

Check that if we request bottom-up allocation from drm_mm_insert_node() we receive the next available hole from the bottom. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1

[Intel-gfx] [PATCH v2 22/40] drm/i915: Build DRM range manager selftests for CI

Build the struct drm_mm selftests so that we can trivially run them within our CI. "Enable debug, become developer." - Joonas Lahtinen Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/Kconfig.debug | 1

[Intel-gfx] [PATCH v2 35/40] drm: Apply tight eviction scanning to color_adjust

Using mm->color_adjust makes the eviction scanner much tricker since we don't know the actual neighbours of the target hole until after it is created (after scanning is complete). To work out whether we need to evict the neighbours because they impact upon the hole, we have to then check the hole

[Intel-gfx] [PATCH v2 15/40] drm: kselftest for drm_mm and alignment

Check that we can request alignment to any power-of-two or prime using a plain drm_mm_node_insert(), and also handle a reasonable selection of primes. v2: Exercise all allocation flags Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 37/40] drm: Apply range restriction after color adjustment when allocation

mm->color_adjust() compares the hole with its neighbouring nodes. They only abutt before we restrict the hole, so we have to apply color_adjust before we apply the range restriction. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm.c | 16 ++-- 1 file

[Intel-gfx] [PATCH v2 13/40] drm: kselftest for drm_mm_replace_node()

Reuse drm_mm_insert_node() with a temporary node to exercise drm_mm_replace_node(). We use the previous test in order to exercise the various lists following replacement. v2: Check that we copy across the important (user) details of the node. The internal details (such as lists and hole tracking)

[Intel-gfx] [PATCH v2 14/40] drm: kselftest for drm_mm_insert_node_in_range()

Exercise drm_mm_insert_node_in_range(), check that we only allocate from the specified range. v2: Use all allocation flags Signed-off-by: Chris Wilson --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 + drivers/gpu/drm/selftests/test-drm_mm.c | 246

[Intel-gfx] [PATCH v2 10/40] drm: kselftest for drm_mm_debug()

Simple test to just exercise calling the debug dumper on the drm_mm. Signed-off-by: Chris Wilson --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 + drivers/gpu/drm/selftests/test-drm_mm.c | 35 2 files changed, 36 insertions(+)

[Intel-gfx] [PATCH v2 38/40] drm: Use drm_mm_insert_node_in_range_generic() for everyone

Remove a superfluous helper as drm_mm_insert_node is equivalent to insert_node_in_range with a range of (0, U64_MAX). Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm.c | 166 --- include/drm/drm_mm.h | 90

[Intel-gfx] [PATCH v2 20/40] drm: kselftest for drm_mm and color eviction

Check that after applying the driver's color adjustment, eviction scanning find a suitable hole. Signed-off-by: Chris Wilson --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 + drivers/gpu/drm/selftests/test-drm_mm.c | 159 +++ 2

[Intel-gfx] [PATCH v2 39/40] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees

The drm_mm range manager claimed to support top-down insertion, but it was neither searching for the top-most hole that could fit the allocation request nor fitting the request to the hole correctly. In order to search the range efficiently, we create a secondary index for the holes using either

[Intel-gfx] [PATCH v2 28/40] drm: Extract struct drm_mm_scan from struct drm_mm

The scan state occupies a large proportion of the struct drm_mm and is rarely used and only contains temporary state. That makes it suitable to moving to its struct and onto the stack of the callers. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 07/40] drm: Add a simple generator of random permutations

When testing, we want a random but yet reproducible order in which to process elements. Here we create an array which is a random (using the Tausworthe PRNG) permutation of the order in which to execute. v2: Tidier code by David Herrmann Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [PATCH v2 36/40] drm: Wrap drm_mm_node.hole_follows

Insulate users from changed to the internal hole tracking within struct drm_mm_node by using an accessor for hole_follows. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm.c| 12 ++-- drivers/gpu/drm/i915/i915_vma.c | 4 ++--

[Intel-gfx] [PATCH v2 32/40] drm: Compute tight evictions for drm_mm_scan

Compute the minimal required hole during scan and only evict those nodes that overlap. This enables us to reduce the number of nodes we need to evict to the bare minimum. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH v2 21/40] drm: kselftest for drm_mm and restricted color eviction

Check that after applying the driver's color adjustment, restricted eviction scanning find a suitable hole. Signed-off-by: Chris Wilson --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 + drivers/gpu/drm/selftests/test-drm_mm.c | 119

[Intel-gfx] [PATCH v2 11/40] drm: kselftest for drm_mm_reserve_node()

Exercise drm_mm_reserve_node(), check that we can't reserve an already occupied range and that the lists are correct after reserving/removing. v2: Check for invalid node reservation. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 23/40] drm: Promote drm_mm alignment to u64

In places (e.g. i915.ko), the alignment is exported to userspace as u64 and there now exists hardware for which we can indeed utilize a u64 alignment. As such, we need to keep 64bit integers throughout when handling alignment. Testcase: igt/drm_mm/align64 Testcase: igt/gem_exec_alignment

[Intel-gfx] [PATCH v2 17/40] drm: kselftest for drm_mm and range restricted eviction

Check that we add arbitrary blocks to a restrited eviction scanner in order to find the first minimal hole that matches our request. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH v2 34/40] drm: Simplify drm_mm scan-list manipulation

Since we mandate a strict reverse-order of drm_mm_scan_remove_block() after drm_mm_scan_add_block() we can further simplify the list manipulations when generating the temporary scan-hole. v2: Highlight the games being played with the lists to track the scan holes without allocation.

[Intel-gfx] [PATCH v2 04/40] drm: Constify the drm_mm API

Mark up the pointers as constant through the API where appropriate. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm.c| 24 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- include/drm/drm_mm.h| 27

[Intel-gfx] [PATCH v2 19/40] drm: kselftest for drm_mm and color adjustment

Check that after applying the driver's color adjustment, fitting of the node and its alignment are still correct. v2: s/no_color_touching/separate_adjacent_colors/ Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

Re: [Intel-gfx] ??? Fi.CI.BAT: failure for drm/i915: relax uncritical udelay_range() settings

On Fri, Dec 16, 2016 at 07:29:59AM +, Saarinen, Jani wrote: > > == Series Details == > > > > Series: drm/i915: relax uncritical udelay_range() settings > > URL : https://patchwork.freedesktop.org/series/16900/ > > State : failure > > > > == Summary == > > > > Series 16900v1 drm/i915:

[Intel-gfx] [PATCH v2 26/40] drm: Simplify drm_mm_clean()

Since commit ea7b1dd44867 ("drm: mm: track free areas implicitly"), to test whether there are any nodes allocated within the range manager, we merely have to ask whether the node_list is empty. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 27/40] drm: Add asserts to catch overflow in drm_mm_init() and drm_mm_init_scan()

A simple assert to ensure that we don't overflow start + size when initialising the drm_mm, or its scanner. In future, we may want to switch to tracking the value of ranges (rather than size) so that we can cover the full u64, for example like resource tracking. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v2 18/40] drm: kselftest for drm_mm and top-down allocation

Check that if we request top-down allocation from drm_mm_insert_node() we receive the next available hole from the top. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +

[Intel-gfx] [PATCH v2 31/40] drm: Fix application of color vs range restriction when scanning drm_mm

The range restriction should be applied after the color adjustment, or else we may inadvertently apply the color adjustment to the restricted hole (and not against its neighbours). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 24/40] drm: Fix kerneldoc for drm_mm_scan_remove_block()

The nodes must be removed in the *reverse* order. This is correct in the overview, but backwards in the function description. Whilst here add Intel's copyright statement and tweak some formatting. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm.c | 34

[Intel-gfx] [PATCH v2 25/40] drm: Detect overflow in drm_mm_reserve_node()

Protect ourselves from a caller passing in node.start + node.size that will overflow and trick us into reserving that node. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[Intel-gfx] [PATCH v2 29/40] drm: Rename prev_node to hole in drm_mm_scan_add_block()

Acknowledging that we were building up the hole was more useful to me when reading the code, than knowing the relationship between this node and the previous node. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm.c | 16 1 file changed, 8

[Intel-gfx] [PATCH v2 05/40] drm: Compile time enabling for asserts in drm_mm

Use CONFIG_DRM_DEBUG_MM to conditionally enable the internal and validation checking using BUG_ON. Ideally these paths should all be exercised by CI selftests (with the asserts enabled). Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 16/40] drm: kselftest for drm_mm and eviction

Check that we add arbitrary blocks to the eviction scanner in order to find the first minimal hole that matches our request. v2: Refactor out some common eviction code for later Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 12/40] drm: kselftest for drm_mm_insert_node()

Exercise drm_mm_insert_node(), check that we can't overfill a range and that the lists are correct after reserving/removing. v2: Extract helpers for the repeated tests v3: Iterate over all allocation flags Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH v2 30/40] drm: Unconditionally do the range check in drm_mm_scan_add_block()

Doing the check is trivial (low cost in comparison to overall eviction) and helps simplify the code. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/drm_mm.c | 53

[Intel-gfx] [PATCH v2 02/40] drm/i915: Simplify i915_gtt_color_adjust()

If we remember that node_list is a circular list containing the fake head_node, we can use a simple list_next_entry() and skip the NULL check for the allocated check against the head_node. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 01/40] drm/i915: Use the MRU stack search after evicting

When we evict from the GTT to make room for an object, the hole we create is put onto the MRU stack inside the drm_mm range manager. On the next search pass, we can speed up a PIN_HIGH allocation by referencing that stack for the new hole. v2: Pull together the 3 identical implements (ahem, a

[Intel-gfx] [PATCH v2 09/40] drm: kselftest for drm_mm_init()

Simple first test to just exercise initialisation of struct drm_mm. Signed-off-by: Chris Wilson --- drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 + drivers/gpu/drm/selftests/test-drm_mm.c | 114 +++ 2 files changed, 115 insertions(+)

[Intel-gfx] [PATCH v2 06/40] drm: Add some kselftests for the DRM range manager (struct drm_mm)

First we introduce a smattering of infrastructure for writing selftests. The idea is that we have a test module that exercises a particular portion of the exported API, and that module provides a set of tests that can either be run as an ensemble via kselftest or individually via an igt harness

[Intel-gfx] [PATCH v2 03/40] drm: Add drm_mm_for_each_node_safe()

A complement to drm_mm_for_each_node(), wraps list_for_each_entry_safe() for walking the list of nodes safe against removal. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/drm_mm.c | 9 -

[Intel-gfx] [PATCH v2 08/40] drm: Add a simple prime number generator

Prime numbers are interesting for testing components that use multiplies and divides, such as testing struct drm_mm alignment computations. Signed-off-by: Chris Wilson --- drivers/gpu/drm/Kconfig | 4 + drivers/gpu/drm/Makefile| 1 +

[Intel-gfx] drm_mm range manager fixes, take 2

The goal of this series is to fix top-down allocations to be allocated from the top and aligned correctly, introduce bottom-up allocations, and speed up searches and tighten evictions. More polish on the test cases to reduce code duplication and to improve expectation checking. And a little more

Re: [Intel-gfx] [kbuild-all] [PATCH] drm: Convert all helpers to drm_connector_list_iter

to worth the efforts to add auto detect logic for. Thanks, Fengguang On Thu, Dec 15, 2016 at 11:59 PM, kbuild test robot <l...@intel.com> wrote: Hi Daniel, [auto build test ERROR on drm/drm-next] [also build test ERROR on next-20161215] [cannot apply to v4.9] [if your patch is applied to the

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: relax uncritical udelay_range() settings

> == Series Details == > > Series: drm/i915: relax uncritical udelay_range() settings > URL : https://patchwork.freedesktop.org/series/16900/ > State : failure > > == Summary == > > Series 16900v1 drm/i915: relax uncritical udelay_range() settings >

Re: [Intel-gfx] [PATCH] drm: Convert all helpers to drm_connector_list_iter

] > [also build test ERROR on next-20161215] > [cannot apply to v4.9] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Convert-all-helpers-to-drm_connec

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Check num_pipes before initializing audio component

== Series Details == Series: series starting with [1/2] drm/i915: Check num_pipes before initializing audio component URL : https://patchwork.freedesktop.org/series/16902/ State : warning == Summary == Series 16902v1 Series without cover letter

[Intel-gfx] [PATCH 2/2] drm/i915: Check num_pipes before initializing or calling display hooks

From: Elaine Wang when num_pipes is zero, it indicates display doesn't exist, so there is no need to initialize display hooks. And to avoid calling these uninitialized display hooks, respect num_pipes at the beginning of intel_modeset_init_hw and intel_init_clock_gating.

[Intel-gfx] [PATCH 1/2] drm/i915: Check num_pipes before initializing audio component

From: Elaine Wang when num_pipes is zero, it indicates there is no display and HDMI audio doesn't exist. Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Elaine Wang ---

Re: [Intel-gfx] Guc parameter Handling

On 2016.12.15 22:36:40 +, Srivatsa, Anusha wrote: > Hi All, > > > > I was wondering if we intend to keep -1 and 2 for the enable_guc_submission > parameter. Since now we are gating guc loads if either guc_submission or > enable_huc parameter is set, why have a -1(platform default) and

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: relax uncritical udelay_range() settings

== Series Details == Series: drm/i915: relax uncritical udelay_range() settings URL : https://patchwork.freedesktop.org/series/16900/ State : failure == Summary == Series 16900v1 drm/i915: relax uncritical udelay_range() settings

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: relax uncritical udelay_range()

== Series Details == Series: drm/i915: relax uncritical udelay_range() URL : https://patchwork.freedesktop.org/series/16897/ State : success == Summary == Series 16897v1 drm/i915: relax uncritical udelay_range() https://patchwork.freedesktop.org/api/1.0/series/16897/revisions/1/mbox/

[Intel-gfx] [PATCH V2] drm/i915: relax uncritical udelay_range() settings

_64_defconfig (implies CONFIG_DRM_I915) Patch is against 4.9.0 (localversion-next is next-20161215) drivers/gpu/drm/i915/intel_dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c index 5b72c50..92b96fa 100644

[Intel-gfx] [PATCH V2] drm/i915: relax uncritical udelay_range()

with: x86_64_defconfig (implies CONFIG_DRM_I915) Patch is against 4.9.0 (localversion-next is next-20161215) drivers/gpu/drm/i915/intel_dsi_pll.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c b/drivers/gpu/drm/i915/intel_dsi_pll.c index 5

Re: [Intel-gfx] [PATCH v3] drm/i915: Check HAS_PCH_NOP when install or reset dispaly IRQ

> On Thu, 15 Dec 2016, Ville Syrjälä wrote: > > On Mon, Dec 12, 2016 at 02:57:44PM +0800, Wang Elaine wrote: > >> From: Elaine Wang > >> > >> Some platforms don't have display. To avoid accessing the > >> non-existent registers, check

[Intel-gfx] ✓ Fi.CI.BAT: success for HuC Loading Patches

== Series Details == Series: HuC Loading Patches URL : https://patchwork.freedesktop.org/series/16878/ State : success == Summary == Series 16878v1 HuC Loading Patches https://patchwork.freedesktop.org/api/1.0/series/16878/revisions/1/mbox/ fi-bdw-5557u total:247 pass:233 dwarn:0

Re: [Intel-gfx] [PATCH] drm: Convert all helpers to drm_connector_list_iter

Hi Daniel, [auto build test ERROR on drm/drm-next] [also build test ERROR on next-20161215] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Convert-all

Re: [Intel-gfx] [PATCH] drm: Convert all helpers to drm_connector_list_iter

Hi Daniel, [auto build test ERROR on drm/drm-next] [also build test ERROR on next-20161215] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Convert-all

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

On Thu, Dec 15, 2016 at 02:29:50PM -0800, anushasr wrote: > From: Peter Antoine > > This patch will allow for getparams to return the status of the HuC. > As the HuC has to be validated by the GuC this patch uses the validated > status to show when the HuC is loaded and

[Intel-gfx] Guc parameter Handling

Hi All, I was wondering if we intend to keep -1 and 2 for the enable_guc_submission parameter. Since now we are gating guc loads if either guc_submission or enable_huc parameter is set, why have a -1(platform default) and 2(forcefully load) option? We anyway do not have any special default set

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add debugfs for HuC loading status check

From: Peter Antoine Add debugfs entry for HuC loading status check. v2: rebase on-top of drm-intel-nightly. v3: rebased again. v7: rebased. v8: rebased. v9: rebased. v10: rebased. v11: rebased on top of drm-tip v12: rebased. Tested-by: Xiang Haihao

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

From: Peter Antoine This patch will allow for getparams to return the status of the HuC. As the HuC has to be validated by the GuC this patch uses the validated status to show when the HuC is loaded and ready for use. You cannot use the loaded status as with the GuC as

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

From: Anusha Srivatsa This patch adds the HuC Loading for the BXT by using the updated file construction. Version 1.7 of the HuC firmware. v2: rebased. v3: rebased on top of drm-tip v4: rebased. v5: rebased. Rename BXT_FW_MAJOR to BXT_HUC_FW_ Cc: Jeff Mcgee

[Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

From: Peter Antoine The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-intel-nightly. changed name format and upped version 1.7. v3: rebased on top of drm-intel-nightly. v4: changed

[Intel-gfx] [PATCH 0/8] HuC Loading Patches

These patches add HuC loading support. The driver builds a frame level workload which is stored in the graphics memory. This workload is presented to HuC for processing. The driver, therefore should first determine if the HuC is enabled and also read the huC athentication status bit to determine

[Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

From: Anusha Srivatsa This patch adds the support to load HuC on KBL Version 2.0 v2: rebased. v3: rebased on top of drm-tip v4: rebased. v5: rebased. Rename KBL_FW_ to KBL_HUC_FW_ Cc: Jeff Mcgee Signed-off-by: Anusha Srivatsa

[Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

From: Anusha Srivatsa The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is used for both cases. HuC loading needs to be before GuC loading. The WOPCM setting must be done early before loading any of them. v2: rebased on-top of drm-intel-nightly.

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

From: Peter Antoine Rename some of the GuC fw loading code to make them more general. We will utilise them for HuC loading as well. s/intel_guc_fw/intel_uc_fw/g s/GUC_FIRMWARE/UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,

[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

From: Peter Antoine HuC firmware css header has almost exactly same definition as GuC firmware except for the sw_version. Also, add a new member fw_type into intel_uc_fw to indicate what kind of fw it is. So, the loader will pull right sw_version from header. v2:

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Simplify intel_guc_load()

On 15/12/16 07:47, Arkadiusz Hiler wrote: Current version of intel_guc_load() does a lot: - cares about submission - loads huc - implement WA This change offloads some of the logic to intel_uc_load(), which now cares about the above. Cc: Anusha Srivatsa Cc:

Re: [Intel-gfx] [alsa-devel] [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver

On Thu, 15 Dec 2016 21:37:03 +0100, Pierre-Louis Bossart wrote: > > > >>> Subject: Re: [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver > > >>> Why do we need a "shell" and indirect calls? > >>> This is a small driver set, so it's not utterly unacceptable, but it > >>> still makes >

Re: [Intel-gfx] [bug report] drm/i915: Small compaction of the engine init code

On Thu, Dec 15, 2016 at 11:44:13PM +0300, Dan Carpenter wrote: > Hello Tvrtko Ursulin, > > The patch a19d6ff29a82: "drm/i915: Small compaction of the engine > init code" from Jun 23, 2016, leads to the following static checker > warning: > > drivers/gpu/drm/i915/intel_lrc.c:1973

[Intel-gfx] [bug report] drm/i915: Small compaction of the engine init code

Hello Tvrtko Ursulin, The patch a19d6ff29a82: "drm/i915: Small compaction of the engine init code" from Jun 23, 2016, leads to the following static checker warning: drivers/gpu/drm/i915/intel_lrc.c:1973 logical_render_ring_init() warn: passing freed memory 'engine'

Re: [Intel-gfx] [alsa-devel] [PATCH 7/7] ALSA: x86: hdmi: continue playback even when display resolution changes

This change itself is OK, but this made me wonder about the driver implementation: the current MAX_PB=1 is the hardware limitation or the soft limitation? That is, can't we play back two streams when we connect two HDMI monitors? Two streams was never validated from hardware per se. So

Re: [Intel-gfx] [alsa-devel] [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver

Subject: Re: [PATCH 3/7] ALSA: add shell for Intel HDMI LPE audio driver Why do we need a "shell" and indirect calls? This is a small driver set, so it's not utterly unacceptable, but it still makes things a bit more complicated than necessary, so I'd like to understand the idea behind it.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix inconsistent naming of i915_guc_client parameter

== Series Details == Series: drm/i915: Fix inconsistent naming of i915_guc_client parameter URL : https://patchwork.freedesktop.org/series/16869/ State : success == Summary == Series 16869v1 drm/i915: Fix inconsistent naming of i915_guc_client parameter

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Don't populate plane->plane for cursors and sprites

On Thu, Dec 15, 2016 at 05:50:02PM -0200, Paulo Zanoni wrote: > Em Qui, 2016-12-15 às 21:11 +0200, Ville Syrjälä escreveu: > > On Thu, Dec 15, 2016 at 05:05:05PM -0200, Paulo Zanoni wrote: > > > > > > Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com > > > escreveu: > > > > > > >

[Intel-gfx] [PATCH] drm/i915: Fix inconsistent naming of i915_guc_client parameter

We usually use 'client' as identifier for the i915_guc_client. For unknown reason, few functions were using 'gc' name. Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_guc_submission.c | 64 +++--- 1 file changed, 32

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Don't populate plane->plane for cursors and sprites

Em Qui, 2016-12-15 às 21:11 +0200, Ville Syrjälä escreveu: > On Thu, Dec 15, 2016 at 05:05:05PM -0200, Paulo Zanoni wrote: > > > > Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com > > escreveu: > > > > > > From: Ville Syrjälä > > > > > > With

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Add support for audio driver notifications

On 12/14/16 7:13 AM, Takashi Iwai wrote: On Wed, 14 Dec 2016 13:55:52 +0100, Daniel Vetter wrote: Only noticed it here, but why again do we need to re-roll our intel-only hdmi/eld notification? The one we have for hda is somewhat justified since it went in at roughly the same time as the new

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail

== Series Details == Series: drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail URL : https://patchwork.freedesktop.org/series/16863/ State : success == Summary == Series 16863v1 drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Don't populate plane->plane for cursors and sprites

On Thu, Dec 15, 2016 at 05:05:05PM -0200, Paulo Zanoni wrote: > Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com > escreveu: > > From: Ville Syrjälä > > > > With plane->plane now purely reserved for the primary planes, let's > > not even populate it

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Don't populate plane->plane for cursors and sprites

Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > With plane->plane now purely reserved for the primary planes, let's > not even populate it for cursors and sprites. Let's switch the type > to enum plane as well

Re: [Intel-gfx] [alsa-devel] [PATCH 1/7] drm/i915: setup bridge for HDMI LPE audio driver

>>> +static void lpe_audio_irq_unmask(struct irq_data *d) { >>> + struct drm_i915_private *dev_priv = d->chip_data; >>> + unsigned long irqflags; >>> + u32 val = (I915_LPE_PIPE_A_INTERRUPT | >>> + I915_LPE_PIPE_B_INTERRUPT); >> >> PIPE_C missing? >> > > No PIPE_C on vlv Good catch

Re: [Intel-gfx] [PATCH 1/2] drm/i915/huc: Introduce enable_huc parameter

>-Original Message- >From: Wajdeczko, Michal >Sent: Thursday, December 15, 2016 10:32 AM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani >Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/huc: Introduce enable_huc

Re: [Intel-gfx] [PATCH 7/9] drm/i915: s/plane/plane_id/ in skl+ plane register defines

Em Ter, 2016-11-22 às 18:02 +0200, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Rename the SKL plane register define 'plane' parameter to 'plane_id' > to > reflect the fact that you're supposed to pass in the enum plane_id > rather than enum

Re: [Intel-gfx] [PATCH 1/2] drm/i915/huc: Introduce enable_huc parameter

On Thu, Dec 15, 2016 at 10:24:56AM -0800, anushasr wrote: > From: Anusha Srivatsa > > Add a new kernel parameter: enable_huc. This parameter > controls HuC functionality. If this parameter > is set to 1, it suggests that HuC functionality is being > used and also that

[Intel-gfx] [PATCH 1/2] drm/i915/huc: Introduce enable_huc parameter

From: Anusha Srivatsa Add a new kernel parameter: enable_huc. This parameter controls HuC functionality. If this parameter is set to 1, it suggests that HuC functionality is being used and also that the GuC has to be loaded. GuC has to be loaded in order to

[Intel-gfx] [PATCH 2/2] drm/i915/guc: Remove enable_guc_loading parameter.

Remove the enable_guc_loading parameter. GuC loads are now controlled through enable_huc and enable_guc_submission parameter. If either or both of these parameters are set. GuC is loaded. If we need to debug GuC we can do so by removing the firmware from the rootfs instead of disabling with a

[Intel-gfx] ✗ Fi.CI.BAT: failure for GuC Scrub vol. 1

== Series Details == Series: GuC Scrub vol. 1 URL : https://patchwork.freedesktop.org/series/16856/ State : failure == Summary == Series 16856v1 GuC Scrub vol. 1 https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/1/mbox/ Test drv_module_reload: Subgroup

[Intel-gfx] [PATCH] drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail

From: Ville Syrjälä The scanline counter is bonkers on VLV/CHV DSI. The scanline counter increment is not lined up with the start of vblank like it is on every other platform and output type. This causes problems for both the vblank timestamping and atomic update

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

On Thu, Dec 15, 2016 at 06:42:08PM +0200, Ville Syrjälä wrote: > On Thu, Dec 15, 2016 at 04:41:51PM +0100, Maarten Lankhorst wrote: > > Op 15-12-16 om 16:36 schreef Ville Syrjälä: > > > On Thu, Dec 15, 2016 at 04:28:52PM +0100, Maarten Lankhorst wrote: > > >> Op 15-12-16 om 16:23 schreef Ville

Re: [Intel-gfx] [PATCH 01/14] drm/i915: Track visible planes in a bitmask

On Thu, Dec 15, 2016 at 06:11:24PM +0100, Maarten Lankhorst wrote: > Op 15-12-16 om 16:02 schreef Ville Syrjälä: > > On Thu, Dec 15, 2016 at 03:56:03PM +0100, Maarten Lankhorst wrote: > >> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com: > >>> From: Ville Syrjälä

Re: [Intel-gfx] [PATCH 07/13] drm: Clean up connectors by unreferencing them

On 2016-12-13 06:08 PM, Daniel Vetter wrote: Only static connectors should be left at this point, and we should be able to clean them out by simply dropping that last reference still around from drm_connector_init. If that leaves anything behind then we have a driver bug. Doing the final

Re: [Intel-gfx] [PATCH 07/14] drm/i915: Compute vlv/chv wms the atomic way

On Thu, Dec 15, 2016 at 06:12:12PM +0100, Maarten Lankhorst wrote: > Op 15-12-16 om 17:09 schreef Ville Syrjälä: > > On Thu, Dec 15, 2016 at 04:45:49PM +0100, Maarten Lankhorst wrote: > >> Op 15-12-16 om 16:38 schreef Ville Syrjälä: > >>> On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: use udelay for very small delays

== Series Details == Series: drm/i915: use udelay for very small delays URL : https://patchwork.freedesktop.org/series/16852/ State : success == Summary == Series 16852v1 drm/i915: use udelay for very small delays https://patchwork.freedesktop.org/api/1.0/series/16852/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 07/14] drm/i915: Compute vlv/chv wms the atomic way

Op 15-12-16 om 17:09 schreef Ville Syrjälä: > On Thu, Dec 15, 2016 at 04:45:49PM +0100, Maarten Lankhorst wrote: >> Op 15-12-16 om 16:38 schreef Ville Syrjälä: >>> On Thu, Dec 15, 2016 at 04:30:54PM +0100, Maarten Lankhorst wrote: Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com:

Re: [Intel-gfx] [PATCH 01/14] drm/i915: Track visible planes in a bitmask

Op 15-12-16 om 16:02 schreef Ville Syrjälä: > On Thu, Dec 15, 2016 at 03:56:03PM +0100, Maarten Lankhorst wrote: >> Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com: >>> From: Ville Syrjälä >>> >>> In a lot of place we wish to know which planes on the crtc

Re: [Intel-gfx] [PATCH 14/14] drm/i915: Kill level 0 wm hack for VLV/CHV

Op 12-12-16 om 21:35 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä > > We now compute the watermarks correctly, so just return an error if we > can't support the configuration. > > Signed-off-by: Ville Syrjälä > --- >

Re: [Intel-gfx] [PATCH v2] drm/i915: Optimise VMA lookup slightly

On Thu, Dec 15, 2016 at 04:49:49PM +, Tvrtko Ursulin wrote: > > On 13/12/2016 14:47, Chris Wilson wrote: > >On Tue, Dec 13, 2016 at 02:37:27PM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Cast VM pointers before substraction to save the compiler >

Re: [Intel-gfx] [PATCH v7 8/8] drm/i915/gen9: WM memory bandwidth related workaround

Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu: > This patch implemnets Workariunds related to display arbitrated > memory > bandwidth. These WA are applicabe for all gen-9 based platforms. 3 typos above. The WA is already implemented. What the patch does is that it opts-out of the WA

  1   2   3   >