Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic.

Op 13-03-17 om 10:29 schreef Ville Syrjälä: > On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote: >> Op 09-03-17 om 18:36 schreef Ville Syrjälä: >>> On Thu, Mar 09, 2017 at 02:06:15PM +0100, Maarten Lankhorst wrote: As a proof of concept, first try to convert intel_tv, which is

Re: [Intel-gfx] FW: [PATCH] drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support

On Mon, Mar 13, 2017 at 12:22:53PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > From: Ville Syrjälä > > > > Check that the sink really declared 12bpc support before we enable it. > > This should not actually never happen since it's mandatory for

Re: [Intel-gfx] [10/11] drm/i915/guc: Refactor the concept "GuC context descriptor" into "GuC stage descriptor"

On Fri, Mar 10, 2017 at 08:28:57AM -0800, Oscar Mateo wrote: > A GuC context and a HW context are in no way related, so the name "GuC > context descriptor" > is very unfortunate, because a new reader of the code gets overwhelmed very > quickly with > a lot of things called "context" that refer

Re: [Intel-gfx] [bug report] drm/i915: Live testing for context execution

On Mon, Mar 13, 2017 at 03:34:29PM +0300, Dan Carpenter wrote: > Hello Chris Wilson, > > The patch 791ff39ae32a: "drm/i915: Live testing for context > execution" from Feb 13, 2017, leads to the following static checker > warning: > > drivers/gpu/drm/i915/selftests/i915_gem_context.c:347

[Intel-gfx] [PATCH] drm/i915/selftests: Catch error from mock_file()

The patch 791ff39ae32a: "drm/i915: Live testing for context execution" from Feb 13, 2017, leads to the following static checker warning: drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec() error: 'file' dereferencing possible ERR_PTR() Reported-by: Dan Carpenter

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

On Mon, Mar 13, 2017 at 12:43:56PM +0200, Petri Latvala wrote: > v2 of the series with miscellaneous fixes. > > IGT subtest enumeration must work regardless of what the running > environment is. Kernel selftest launchers want to expose everything > the running kernel can execute. > > These two

Re: [Intel-gfx] [PATCH v6] drm/i915/guc: Simplify intel_guc_init_hw()

On Fri, Mar 10, 2017 at 01:11:06PM +0100, Michal Wajdeczko wrote: > On Fri, Mar 10, 2017 at 12:46:06PM +0100, Arkadiusz Hiler wrote: > > Current version of intel_guc_init_hw() does a lot: > > - cares about submission > > - loads huc > > - implement WA > > > > This change offloads some of the

Re: [Intel-gfx] [PATCH] drm/i915: Inline gen6_sanitize_rps_pm_mask()

Chris Wilson writes: > gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the > object code. > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/i915_irq.c | 5 -

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Catch error from mock_file()

== Series Details == Series: drm/i915/selftests: Catch error from mock_file() URL : https://patchwork.freedesktop.org/series/21156/ State : success == Summary == Series 21156v1 drm/i915/selftests: Catch error from mock_file()

Re: [Intel-gfx] [PATCH] drm/i915: Inline gen6_sanitize_rps_pm_mask()

On Mon, Mar 13, 2017 at 03:15:32PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the > > object code. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix error path for ggtt walk_hole()

== Series Details == Series: drm/i915/selftests: Fix error path for ggtt walk_hole() URL : https://patchwork.freedesktop.org/series/21140/ State : success == Summary == Series 21140v1 drm/i915/selftests: Fix error path for ggtt walk_hole()

[Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

v2 of the series with miscellaneous fixes. IGT subtest enumeration must work regardless of what the running environment is. Kernel selftest launchers want to expose everything the running kernel can execute. These two things are mutually exclusive. This series is an attempt for a

[Intel-gfx] [PATCH i-g-t v2 1/2] lib: Add i915 and drm-mm selftest headers from the kernel

Copied as of commit commit 496b575e3ccbf6fbe57a674c721af43dc8826361 Author: Chris Wilson Date: Mon Feb 13 17:15:58 2017 + drm/i915: Add initial selftests for hang detection and resets The headers are used to enumerate available tests when the running

[Intel-gfx] [PATCH i-g-t v2 2/2] Always expose IGT subtests for known kernel selftests

Even when the running kernel does not support selftests, make subtest enumeration list known kselftests. The list is generated using selftest listing headers copied from the kernel. If the running kernel gains new selftest subtests, they are listed even without copying the headers over and

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote: > Still completely lacking justification. The above is a non sequitur; > static testlist generation can be done just from the source. Static testlist generation can be done and it breaks when run on a kernel without selftests enabled.

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use new atomic iterator macros in display code

Op 13-03-17 om 11:15 schreef Daniel Vetter: > On Thu, Mar 09, 2017 at 03:52:04PM +0100, Maarten Lankhorst wrote: >> Add a big fat warning in __intel_display_resume that the old state is >> invalid, and use the correct state everywhere. >> >> Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH v10 2/6] drm/edid: check for HF-VSDB block

From: Thierry Reding This patch implements a small function that finds if a given CEA db is hdmi-forum vendor specific data block or not. V2: Rebase. V3: Added R-B from Jose. V4: Rebase V5: Rebase V6: Rebase V7: Rebase V8: Rebase V9: Rebase V10: Rebase Signed-off-by:

[Intel-gfx] [PATCH v10 0/6] HDMI 2.0: Scrambling in DRM layer

HDMI 2.0 spec defines a method to reduce the RF footprint while operating at higher pixel clocks, which is called Scrambling. Scrambling can be controlled over a new set of I2C registers which are accessible over existing DDC I2C lines, called SCDC register set. This patch series contains 6

[Intel-gfx] [PATCH v10 3/6] drm/edid: detect SCDC support in HF-VSDB

This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected

[Intel-gfx] [PATCH v10 1/6] drm: Add SCDC helpers

From: Thierry Reding SCDC is a mechanism defined in the HDMI 2.0 specification that allows the source and sink devices to communicate. This commit introduces helpers to access the SCDC and provides the symbolic names for the various registers defined in the specification.

[Intel-gfx] [PATCH v10 4/6] drm/edid: detect SCDC support in HF-VSDB

This patch does following: - Adds a new structure (drm_hdmi_info) in drm_display_info. This structure will be used to save and indicate if sink supports advanced HDMI 2.0 features - Adds another structure drm_scdc within drm_hdmi_info, to reflect scdc support and capabilities in connected

Re: [Intel-gfx] [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating

On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote: > Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go > to zero after updating db_status before we call the GuC to release the > doorbell. Does this fix some of the '110' errors? -Chris -- Chris Wilson, Intel Open

Re: [Intel-gfx] [03/11 v3] drm/i915/guc: Add onion teardown to the GuC setup

On Fri, Mar 10, 2017 at 08:28:50AM -0800, Oscar Mateo wrote: > Starting with intel_guc_loader, down to intel_guc_submission > and finally to intel_guc_log. > > v2: > - Null execbuf client outside guc_client_free (Daniele) > - Assert if things try to get allocated twice (Daniele/Joonas) > -

Re: [Intel-gfx] FW: [PATCH] drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support

Regards Shashank On 3/13/2017 12:53 PM, Ville Syrjälä wrote: On Mon, Mar 13, 2017 at 12:22:53PM +0200, Sharma, Shashank wrote: Regards Shashank From: Ville Syrjälä Check that the sink really declared 12bpc support before we enable it. This should not

Re: [Intel-gfx] [PATCH 0/5] drm/i915: Use new atomic iterator macros.

Op 09-03-17 om 19:35 schreef Ville Syrjälä: > On Thu, Mar 09, 2017 at 03:52:00PM +0100, Maarten Lankhorst wrote: >> Some small patchset to deal with the atomic iterator changes. >> >> Maarten Lankhorst (5): >> drm/i915: Use new atomic iterator macros in ddi >> drm/i915: Use new atomic iterator

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

Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher clocks, for reduced RF footprint. This patch checks if the monitor supports scrambling, and if required, enables it during the modeset.

[Intel-gfx] [PATCH v10 6/6] drm/i915: allow HDMI 2.0 clock rates

Geminilake has a native HDMI 2.0 controller, which is capable of driving clocks upto 594Mhz. This patch updates the max tmds clock limit for the same. V2: rebase V3: rebase V4: added r-b from Ander V5: rebase V6: rebase V7: rebase V8: rebase V9: rebase V10: rebase Cc: Ander Conselvan De Oliveira

[Intel-gfx] [PATCH] drm/i915: Add i810/i815 pci-ids for completeness

To improve our historical record and to simplify userspace that wants to include i915_pciids.h as its canonical breakdown of PCI IDs and their respective generations, include the gen1 ids for i810 and i815. Signed-off-by: Chris Wilson --- include/drm/i915_pciids.h | 8

Re: [Intel-gfx] intel graphics hd 530 problem: screen splitted 2 parts horizontally

On Mon, 13 Mar 2017, "M. selcuk karaca" wrote: > we have "HP ProOne 600 G2 21.5-in Touch AiO" PC, equipped with "Intel > HD Graphics 530" graphics card > > We are using debian stretch (testing) based linux distro named pardus. > But we have observed the same

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add i810/i815 pci-ids for completeness

== Series Details == Series: drm/i915: Add i810/i815 pci-ids for completeness URL : https://patchwork.freedesktop.org/series/21149/ State : failure == Summary == Series 21149v1 drm/i915: Add i810/i815 pci-ids for completeness

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Catch error from mock_file()

On 13/03/2017 12:47, Chris Wilson wrote: The patch 791ff39ae32a: "drm/i915: Live testing for context execution" from Feb 13, 2017, leads to the following static checker warning: drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec() error: 'file' dereferencing

[Intel-gfx] [PATCH v8 00/11] GuC Scrub vol. 1

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

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

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

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

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

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

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

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

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

[Intel-gfx] [PATCH 11/11] HAX enable GuC for CI

--- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index b6a7e36..9dcc8a0 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Intel-gfx] The i915 stable patch marking is totally broken

On Mon, 13 Mar 2017, Daniel Vetter wrote: > Our cherry-pick sha1 work exactly like yours: They don't make sense > when you only look at the tree a patch has been cherry-picked _to_, > since they're the sha1 from the tree they've been cherry-picked > _from_. When you clone a fresh

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic.

On Mon, Mar 13, 2017 at 11:38:33AM +0100, Maarten Lankhorst wrote: > Op 13-03-17 om 10:29 schreef Ville Syrjälä: > > On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote: > >> Op 09-03-17 om 18:36 schreef Ville Syrjälä: > >>> On Thu, Mar 09, 2017 at 02:06:15PM +0100, Maarten Lankhorst

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic.

Op 13-03-17 om 11:55 schreef Ville Syrjälä: > On Mon, Mar 13, 2017 at 11:38:33AM +0100, Maarten Lankhorst wrote: >> Op 13-03-17 om 10:29 schreef Ville Syrjälä: >>> On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote: Op 09-03-17 om 18:36 schreef Ville Syrjälä: > On Thu, Mar

[Intel-gfx] [bug report] drm/i915: Live testing for context execution

Hello Chris Wilson, The patch 791ff39ae32a: "drm/i915: Live testing for context execution" from Feb 13, 2017, leads to the following static checker warning: drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec() error: 'file' dereferencing possible ERR_PTR()

Re: [Intel-gfx] [PATCH] drm/i915: Add i810/i815 pci-ids for completeness

On Mon, 13 Mar 2017, Chris Wilson wrote: > To improve our historical record and to simplify userspace that wants to > include i915_pciids.h as its canonical breakdown of PCI IDs and their > respective generations, include the gen1 ids for i810 and i815. Is this how you

[Intel-gfx] [PATCH i-g-t] Update MAINTAINERS file

Signed-off-by: Petri Latvala --- Marius has stepped down from being a maintainer a while ago, it's time to make the file match reality. I'd like to take this opportunity to thank Marius for his work and wish him the best in his new endeavours. MAINTAINERS | 1 - 1

[Intel-gfx] ✓ Fi.CI.BAT: success for HDMI 2.0: Scrambling in DRM layer (rev10)

== Series Details == Series: HDMI 2.0: Scrambling in DRM layer (rev10) URL : https://patchwork.freedesktop.org/series/19161/ State : success == Summary == Series 19161v10 HDMI 2.0: Scrambling in DRM layer https://patchwork.freedesktop.org/api/1.0/series/19161/revisions/10/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915: Add i810/i815 pci-ids for completeness

On Mon, Mar 13, 2017 at 03:04:21PM +0200, Jani Nikula wrote: > On Mon, 13 Mar 2017, Chris Wilson wrote: > > To improve our historical record and to simplify userspace that wants to > > include i915_pciids.h as its canonical breakdown of PCI IDs and their > > respective

Re: [Intel-gfx] [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping.

On Sun, Mar 12, 2017 at 06:19:17PM +0100, David Weinehall wrote: > On Sun, Mar 12, 2017 at 01:21:12PM +, Chris Wilson wrote: > > On Fri, Mar 10, 2017 at 05:14:32PM -0800, Kenneth Graunke wrote: > > > On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has > > > had the surprising

Re: [Intel-gfx] [PATCH] drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info

Chris Wilson writes: > i915_drpc_info missed covering a few register read with the runtime pm > wakelock. Be simple and cover the entire function with a single wakelock > so that new additions are not similarly missed in future. > > WARNING: CPU: 2 PID: 1334 at

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote: > On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote: > > Still completely lacking justification. The above is a non sequitur; > > static testlist generation can be done just from the source. > > Static testlist generation

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

On Mon, Mar 13, 2017 at 04:29:47PM +0200, Petri Latvala wrote: > On Mon, Mar 13, 2017 at 02:15:34PM +, Chris Wilson wrote: > > On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote: > > > On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote: > > > > Still completely lacking

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

On Mon, Mar 13, 2017 at 01:39:45PM +, Tvrtko Ursulin wrote: > > On 13/03/2017 13:15, Arkadiusz Hiler wrote: > > Currently fw->path values can represent one of three possible states: > > > > 1) NULL - device without the uC > > 2) '\0' - device with the uC but have no firmware > > 3) else -

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

On Mon, Mar 13, 2017 at 02:15:34PM +, Chris Wilson wrote: > On Mon, Mar 13, 2017 at 01:02:04PM +0200, Petri Latvala wrote: > > On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote: > > > Still completely lacking justification. The above is a non sequitur; > > > static testlist

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Catch error from mock_file()

On Mon, Mar 13, 2017 at 12:54:15PM +, Tvrtko Ursulin wrote: > > On 13/03/2017 12:47, Chris Wilson wrote: > >The patch 791ff39ae32a: "drm/i915: Live testing for context > >execution" from Feb 13, 2017, leads to the following static checker > >warning: > > > >

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix error path for ggtt walk_hole()

On Mon, Mar 13, 2017 at 10:33:35AM +, Matthew Auld wrote: > On 13 March 2017 at 10:07, Chris Wilson wrote: > > The patch 6e32ab3d4777: "drm/i915: Fill different pages of the GTT" > > from Feb 13, 2017, leads to the following static checker warning: > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Move whole object to CPU domain for coherent shmem access

On Mon, Mar 13, 2017 at 11:06:20AM +0200, Joonas Lahtinen wrote: > On pe, 2017-03-10 at 00:09 +, Chris Wilson wrote: > > If the object is coherent, we can simply update the cache domain on the > > whole object rather than calculate the before/after clflushes. The > > advantage is that we then

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

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

Re: [Intel-gfx] [PATCH] drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info

On Mon, Mar 13, 2017 at 03:41:34PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > i915_drpc_info missed covering a few register read with the runtime pm > > wakelock. Be simple and cover the entire function with a single wakelock > > so that new additions are

Re: [Intel-gfx] [PATCH] drm/i915: Rename REDIRECT_TO_GUC bit

On Mon, Mar 13, 2017 at 10:17:25AM +0530, Kamble, Sagar A wrote: > LGTM. > Reviewed-by: Sagar Arun Kamble [1] Thanks, pushed -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list

[Intel-gfx] [ANNOUNCE] intel-gpu-tools 1.18

A new intel-gpu-tools quarterly release is available with the following changes: Library changes: - Various changes to library functions so that they don't assume Intel hardware. (Lyude) - Added helper functions for managing synchronization primitives. (Robert Foss) - Added support for the

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

On 13/03/2017 13:15, Arkadiusz Hiler wrote: Currently fw->path values can represent one of three possible states: 1) NULL - device without the uC 2) '\0' - device with the uC but have no firmware 3) else - device with the uC and we have firmware Second case is used only to WARN at a later

Re: [Intel-gfx] [PATCH] drm/i915: Inline gen6_sanitize_rps_pm_mask()

On Mon, Mar 13, 2017 at 01:24:41PM +, Chris Wilson wrote: > On Mon, Mar 13, 2017 at 03:15:32PM +0200, Mika Kuoppala wrote: > > Chris Wilson writes: > > > > > gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the > > > object code. > > > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info

On Mon, Mar 13, 2017 at 03:41:34PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > > i915_drpc_info missed covering a few register read with the runtime pm > > wakelock. Be simple and cover the entire function with a single wakelock > > so that new additions are

Re: [Intel-gfx] [PATCH i-g-t v2 0/2] Kernel selftest plumbing

For the record, I pushed this series so I could get the IGT release out. I'm sure there are various ways this functionality can be improved, so constructive suggestions are still definitely welcome. -- Petri Latvala ___ Intel-gfx mailing list

[Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

As a proof of concept, first try to convert intel_tv, which is a rarely used connector. It has 5 properties, tv format and 4 margins. I'm less certain about the state behavior itself, should we pass a size parameter to intel_connector_alloc instead, so duplicate_state can be done globally if it

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: > As a proof of concept, first try to convert intel_tv, which is a rarely > used connector. It has 5 properties, tv format and 4 margins. > > I'm less certain about the state behavior itself, should we pass a size > parameter to

Re: [Intel-gfx] [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating

On 03/13/2017 04:46 AM, Chris Wilson wrote: On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote: Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go to zero after updating db_status before we call the GuC to release the doorbell. Does this fix some of the '110'

[Intel-gfx] [PATCH] drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

In order to prevent accessing the hpd registers outside of the display power wells, we should refrain from writing to the registers before the display interrupts are enabled. [4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915]

Re: [Intel-gfx] [PATCH 23/24] drm: Create DEFINE_DRM_GEM_CMA_FOPS and roll it out to drivers

On Wed, Mar 08, 2017 at 03:12:56PM +0100, Daniel Vetter wrote: > Less code ftw. > > This converts all drivers except the tinydrm helper module. That one > needs more work, since it gets the THIS_MODULE reference from > tinydrm.ko instead of the actual driver module like it should. > Probably

Re: [Intel-gfx] FW: [PATCH] drm/i915: Reject HDMI 12bpc if the sink doesn't indicate support

On Mon, Mar 13, 2017 at 01:09:10PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/13/2017 12:53 PM, Ville Syrjälä wrote: > > On Mon, Mar 13, 2017 at 12:22:53PM +0200, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >>> From: Ville Syrjälä

[Intel-gfx] [PATCH 1/2] drm/i915: Split GEM resetting into 3 phases

Currently we do a reset prepare/finish around the call to reset the GPU, but it looks like we need a later stage after the hw has been reinitialised to allow GEM to restart itself. Start by splitting the 2 GEM phases into 3: prepare - before the reset, check if GEM recovered, then stop GEM

[Intel-gfx] [PATCH 2/2] drm/i915: Disable engine->irq_tasklet around resets

When we restart the engines, and we have active requests, a request on the first engine may complete and queue a request to the second engine before we try to restart the second engine. That queueing of the request may race with the engine to restart, and so may corrupt the current state.

[Intel-gfx] Fixes that failed to backport to v4.11-rc1

I'm already scripting my fixes backports quite a bit, and frankly don't really manually backport anything that doesn't apply cleanly. I'm thinking of automating some "failed to backport" reporting to authors, not unlike the failed stable backport reports. This is a manual report that the

Re: [Intel-gfx] [PATCH 2/2] drm/i915/vbt: split out defaults that are set when there is no VBT

On Mon, Mar 13, 2017 at 11:55:31AM +0200, Jani Nikula wrote: > On Sat, 11 Mar 2017, Manasi Navare wrote: > > On Fri, Mar 10, 2017 at 03:27:58PM +0200, Jani Nikula wrote: > >> The main thing are the DDI ports. If there's a VBT that says there are > >> no outputs, we

[Intel-gfx] [PATCH] drm/i915: Stop using RP_DOWN_EI on Baytrail

On Baytrail, we manually calculate busyness over the evaluation interval to avoid issues with miscaluations with RC6 enabled. However, it turns out that the DOWN_EI interrupt generator is completely bust - it operates in two modes, continuous or never. Neither of which are conducive to good

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

Op 13-03-17 om 17:22 schreef Ville Syrjälä: > On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: >> As a proof of concept, first try to convert intel_tv, which is a rarely >> used connector. It has 5 properties, tv format and 4 margins. >> >> I'm less certain about the state

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

On Mon, Mar 13, 2017 at 05:35:42PM +0100, Maarten Lankhorst wrote: > Op 13-03-17 om 17:22 schreef Ville Syrjälä: > > On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: > >> As a proof of concept, first try to convert intel_tv, which is a rarely > >> used connector. It has 5

Re: [Intel-gfx] [PATCH 08/24] drm: Remove DRM_MINOR_CNT

On Wed, Mar 08, 2017 at 03:12:41PM +0100, Daniel Vetter wrote: > This was originally added by David Herrmann for range checks, but > entirely unused. It confused me, so let's remove it. > > Cc: David Herrmann > Signed-off-by: Daniel Vetter

Re: [Intel-gfx] [PATCH 10/24] drm: Remove drm_pending_event->pid

On Wed, Mar 08, 2017 at 03:12:43PM +0100, Daniel Vetter wrote: > We might as well dump the drm_file pointer, that's about as useful > a cookie as the pid. Noticed while typing docs for drm_file and friends. > > Since the only consumer of this is the tracepoints I think we can safely > change this

[Intel-gfx] [PATCH] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

From: Kenneth Graunke This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 (indicating the optional feature is not supported), and makes execbuf always return -EINVAL if the flags are used. Apparently, no userspace ever shipped which used this optional

Re: [Intel-gfx] [PATCH 02/24] drm: Extract drm_prime.h

On Wed, Mar 08, 2017 at 03:12:35PM +0100, Daniel Vetter wrote: > Plus a little bit more documentation. > > v2: Untangle the missing forward decls to make drm_prime|gem.h > free-standing. > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-mm.rst | 3 ++ >

Re: [Intel-gfx] [10/11] drm/i915/guc: Refactor the concept "GuC context descriptor" into "GuC stage descriptor"

On 03/13/2017 04:49 AM, Chris Wilson wrote: On Fri, Mar 10, 2017 at 08:28:57AM -0800, Oscar Mateo wrote: A GuC context and a HW context are in no way related, so the name "GuC context descriptor" is very unfortunate, because a new reader of the code gets overwhelmed very quickly with a lot

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

Op 13-03-17 om 17:44 schreef Ville Syrjälä: > On Mon, Mar 13, 2017 at 05:35:42PM +0100, Maarten Lankhorst wrote: >> Op 13-03-17 om 17:22 schreef Ville Syrjälä: >>> On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: As a proof of concept, first try to convert intel_tv, which is

Re: [Intel-gfx] The i915 stable patch marking is totally broken

On Sun, Mar 12, 2017 at 10:52 PM, Greg KH wrote: > Why don't the maintainers know which tree to put them in when they are > submitted? As an example, if I get a patch that needs to go to Linus, I > put it in my usb-linus branch, and when it hits a -rc release, I then

Re: [Intel-gfx] The i915 stable patch marking is totally broken

On Sun, Mar 12, 2017 at 11:01 PM, Greg KH wrote: >> So I blame this on flight level 350, but we discussed this at kernel >> summit. Every patch we cherry-pick over comes with a "cherry-picked from >> $sha1" line, as long as you ignore any such sha1 as duplicate you

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Read link status more times when EQ not done (rev4)

== Series Details == Series: drm/i915/dp: Read link status more times when EQ not done (rev4) URL : https://patchwork.freedesktop.org/series/18982/ State : success == Summary == Series 18982v4 drm/i915/dp: Read link status more times when EQ not done

Re: [Intel-gfx] [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping.

On Sun, Mar 12, 2017 at 03:07:14PM -0700, Kenneth Graunke wrote: > On Sunday, March 12, 2017 6:21:12 AM PDT Chris Wilson wrote: > > On Fri, Mar 10, 2017 at 05:14:32PM -0800, Kenneth Graunke wrote: > > > On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has > > > had the surprising

Re: [Intel-gfx] [PULL] topic/designware-baytrail for 4.12 [UPDATED]

On Thu, Mar 02, 2017 at 04:56:49PM +0100, Daniel Vetter wrote: > Hi Dave, > > topic/designware-baytrail-2017-03-02: > Baytrail PMIC vs. PMU race fixes from Hans de Goede > > This time the right version (v4), with the compile fix. > > Updated pull request with new tag, same story as before > >

Re: [Intel-gfx] [PATCH 0/7] DisplayPort audio support on Cherrytrail

On Tue, Jan 31, 2017 at 10:36:42PM +0100, Takashi Iwai wrote: > Hi, > > the following patches enable DisplayPort Audio on Cherrytrail machines > when applied on top of my topic/intel-lpe-audio branch. Tests of DP > audio were run on Dell Wyse 3040. The regression test were performed > on

[Intel-gfx] intel graphics hd 530 problem: screen splitted 2 parts horizontally

Hi we have "HP ProOne 600 G2 21.5-in Touch AiO" PC, equipped with "Intel HD Graphics 530" graphics card We are using debian stretch (testing) based linux distro named pardus. But we have observed the same condition under ubuntu 16.04 LTS. our problem is: screen divided half horizontally.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Use drm_connector_list_iter in debugfs

On Mon, 13 Mar 2017, Daniel Vetter wrote: > On Thu, Mar 09, 2017 at 12:48:56PM +0200, Jani Nikula wrote: >> On Thu, 09 Mar 2017, Daniel Vetter wrote: >> > On Wed, Mar 01, 2017 at 10:52:35AM -, Patchwork wrote: >> >> == Series Details == >> >> >> >> Series:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/vbt: defaults handling for no VBT case

== Series Details == Series: drm/i915/vbt: defaults handling for no VBT case URL : https://patchwork.freedesktop.org/series/21061/ State : success == Summary == Series 21061v1 drm/i915/vbt: defaults handling for no VBT case

[Intel-gfx] [bug report] drm/i915: Fill different pages of the GTT

Hello Chris Wilson, The patch 6e32ab3d4777: "drm/i915: Fill different pages of the GTT" from Feb 13, 2017, leads to the following static checker warning: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:583 walk_hole() error: 'vma' dereferencing possible ERR_PTR()

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic.

On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote: > Op 09-03-17 om 18:36 schreef Ville Syrjälä: > > On Thu, Mar 09, 2017 at 02:06:15PM +0100, Maarten Lankhorst wrote: > >> As a proof of concept, first try to convert intel_tv, which is a rarely > >> used connector. It has 5

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Remove bogus retry around i915_wait_request

On Mon, Mar 13, 2017 at 09:21:58AM +, Dong, Chuanxiao wrote: > > > > -Original Message- > > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > > Behalf Of Dong, Chuanxiao > > Sent: Thursday, March 9, 2017 9:28 AM > > To: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Remove bogus retry around i915_wait_request

> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Chris Wilson > Sent: Monday, March 13, 2017 5:28 PM > To: Dong, Chuanxiao > Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;

  1   2   >