[Intel-gfx] Intel eDP and fixed_mode probing/initialization

Hoping someone can point me in the right direction to understanding how intel_connector->panel.fixed_mode gets probed, as it's referenced in function "intel_dp_mode_valid" at drivers/gpu/drm/i915/intel_dp.c. I am working with a panel hooked up via DSUB to a port that is internally wired as eDP-1.

[Intel-gfx] [PATCH 0/5] Add automation support for DP compliance Tests

This patch series adds the automation support for DP Compliance Tests for EDID and Video Pattern generation from CTS specification 1.2 Rev 1.1. Jim Bride (1): Add support for forcing 6 bpc on DP pipes. Manasi Navare (4): drm/i915: Invoke the DP Compliance test request handler in the short

[Intel-gfx] [PATCH 4/5] Add support for forcing 6 bpc on DP pipes.

From: Jim Bride For DP compliance we need to be able to control the output color type for the pipe associated with the DP port. To do this we rely on the intel_dp_test_force_bpc debugfs file and the associated value stored in struct intel_dp. If the debugfs file has a

[Intel-gfx] [PATCH 3/5] drm/i915: Fixes to support the DP Compliance EDID tests.

This patch addresses a few issues from the original patch for DP Compliance EDID test support submitted by Todd Previte Video Mode requested in the EDID test handler for the EDID Read test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec. Intel connector status

[Intel-gfx] [PATCH 5/5] drm/i915: Implement intel_dp_autotest_video_pattern function for DP Video pattern compliance tests

This video pattern test function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The

[Intel-gfx] [PATCH 1/5] drm/i915: Invoke the DP Compliance test request handler in the short pulse path

HPD Short pulse test requests occur for DP Compliance Link Training and Video Pattern tests.The DP Test request handler needs to be invoked by these tests in the short pulse path in order to support automated DP Compliance tests. Signed-off-by: Manasi Navare ---

[Intel-gfx] [PATCH 2/5] drm/i915: Disable the Link training automation support

Kernel does not have automation support for DP compliance Link training tests. So the Link Training test handler should return a TEST_NAK. Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation

This is the userspace component of the Displayport Compliance testing software required for compliance testing of the I915 Display Port driver. This must be running in order to successfully complete Display Port compliance testing. This app and the kernel code that accompanies it has been written

[Intel-gfx] [PATCH v2 1/2] drm/i915/execlists: Refactor common engine setup

Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set together. v3: Sanitize the engine's IMR to

Re: [Intel-gfx] [PATCH v2 06/10] drm/i915: Enable i915 perf stream for Haswell OA unit

> + bo = i915_gem_object_create(dev_priv->dev, OA_BUFFER_SIZE); > + if (bo == NULL) { IS_ERR() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 10/10] drm/i915: Add more Haswell OA metric sets

This adds 'compute', 'compute extended', 'memory reads', 'memory writes' and 'sampler balance' metric sets for Haswell. Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_oa_hsw.c | 483 - 1 file changed, 482 insertions(+), 1

[Intel-gfx] [PATCH v2 09/10] drm/i915: add oa_event_min_timer_exponent sysctl

The minimal sampling period is now configurable via a dev.i915.oa_min_timer_exponent sysctl parameter. Following the precedent set by perf, the default is the minimum that won't (on its own) exceed the default kernel.perf_event_max_sample_rate default of 10 samples/s. Signed-off-by: Robert

[Intel-gfx] [PATCH v2 07/10] drm/i915: advertise available metrics via sysfs

Each metric set is given a sysfs entry like: /sys/class/drm/card0/metrics//id This allows userspace to enumerate the specific sets that are available for the current system. The 'id' file contains an unsigned integer that can be used to open the associated metric set via

[Intel-gfx] [PATCH v2 08/10] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

Consistent with the kernel.perf_event_paranoid sysctl option that can allow non-root users to access system wide cpu metrics, this can optionally allow non-root users to access system wide OA counter metrics from Gen graphics hardware. Signed-off-by: Robert Bragg ---

[Intel-gfx] [PATCH v2 05/10] drm/i915: Add 'render basic' Haswell OA unit config

Adds a static OA unit, MUX + B Counter configuration for basic render metrics on Haswell. This is autogenerated from an internal XML description of metric sets. Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH v2 03/10] drm/i915: return EACCES for check_cmd() failures

check_cmd() is checking whether a command adheres to certain restrictions that ensure it's safe to execute within a privileged batch buffer. Returning false implies a privilege problem, not that the command is invalid. The distinction makes the difference between allowing the buffer to be

[Intel-gfx] [PATCH v2 01/10] drm/i915: Add i915 perf infrastructure

Adds base i915 perf infrastructure for Gen performance metrics. This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 properties to configure a stream of metrics and returns a new fd usable with standard VFS system calls including read() to read typed and sized records; ioctl()

[Intel-gfx] [PATCH v2 04/10] drm/i915: don't whitelist oacontrol in cmd parser

Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable Mesa to expose OA counters via the INTEL_performance_query extension, but the current implementation based on programming OACONTROL

[Intel-gfx] [PATCH v2 00/10] Enable Gen 7 Observation Architecture

Hopefully covers the last issues raised by Chris and addresses the open issue I had with removing OACONTROL from the command parser whitelist. - Robert Robert Bragg (10): drm/i915: Add i915 perf infrastructure drm/i915: rename OACONTROL GEN7_OACONTROL drm/i915: return EACCES for

[Intel-gfx] [PATCH v2 06/10] drm/i915: Enable i915 perf stream for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. Cc: Chris Wilson Signed-off-by: Robert

[Intel-gfx] [PATCH v2 02/10] drm/i915: rename OACONTROL GEN7_OACONTROL

OACONTROL changes quite a bit for gen8, with some bits split out into a per-context OACTXCONTROL register. Rename now before adding more gen7 OA registers Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h

Re: [Intel-gfx] xserver crash with linux 4.6.0-rc3 and later

On Fri, Apr 29, 2016 at 01:25:30PM -0400, John S Gruber wrote: > Starting with linux 4.6.0-rc3 my Ubuntu Wily system no longer allows logons > from > due to an immediate abort in xserver after just after entering my > userid and password. (lightdm drew the sign on screen OK). > > The xserver

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915/execlists: Refactor common engine setup

== Series Details == Series: series starting with [v2,1/2] drm/i915/execlists: Refactor common engine setup URL : https://patchwork.freedesktop.org/series/6549/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/igb/e1000_82575.o CONMK drivers/tty/vt/consolemap_deftbl.c

[Intel-gfx] [PATCH v2 1/2] drm/i915/execlists: Refactor common engine setup

Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set together. v3: Sanitize the engine's IMR to

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk

== Series Details == Series: series starting with [1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk URL : https://patchwork.freedesktop.org/series/6544/ State : success == Summary == Series 6544v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

On Fri, Apr 29, 2016 at 04:44:24PM +0100, Tvrtko Ursulin wrote: > > On 27/04/16 19:03, Dave Gordon wrote: > >Mostly little optimisations; for instance, if the driver is correctly > >following the submission protocol, the "out of space" condition is > >impossible, so the previous runtime WARN_ON()

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

One late comment: On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :)

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

On 27/04/16 19:03, Dave Gordon wrote: Mostly little optimisations; for instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic effect in development

Re: [Intel-gfx] [PATCH] prime_mmap_kms: show case dma-buf new API and processes restrictions

On Mon, Apr 25, 2016 at 11:07:48AM -0300, Tiago Vignatti wrote: > dma-buf new API consists of: > > - mmap(dma_buf_fd): the ability to map a dma-buf file-descriptor to the > user-space, and most importantly, to actually write on the mapped pointer. > Worth to note that the Direct Rendering Manager

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

On 27/04/16 19:03, Dave Gordon wrote: The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process. And all the information the GuC code needs

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

Hi, On 27/04/16 19:03, Dave Gordon wrote: Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for

[Intel-gfx] [PATCH i-g-t] tools/intel_reg_decode: drop confusing use of IS_965()

Unlike in the kernel driver coding style, IS_965() matches the platform and all subsequent ones. Replace IS_965() with suitable but less confusing alternatives. Most occurences are on code paths that only get called for gens 2, 3 and 4, so replace those with IS_GEN4(). In the one other call site

[Intel-gfx] [PATCH i-g-t] lib/intel_chipset: drop unused IS_9XX()

It's also confusing as the style differs from the kernel (exact platform in the kernel vs. the platform and any later ones in igt). Signed-off-by: Jani Nikula --- lib/intel_chipset.h | 8 1 file changed, 8 deletions(-) diff --git a/lib/intel_chipset.h

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Render decompression support for Gen9 and above

On Fri, Apr 29, 2016 at 08:27:00PM +0530, Vandana Kannan wrote: > This patch includes enabling render decompression (RC) after checking > all the requirements (format, tiling, rotation etc.). > > TODO: > 1. Disable stereo 3D when render decomp is enabled (bit 7:6) > 2. Render decompression must

[Intel-gfx] [PATCH 2/2] drm/i915: Add a FIXME about crtc !active vs. watermarks

From: Ville Syrjälä When the crtc is enabled but !active, we should still compute the watermarks as if the planes were visible. That would make it more likely that the we can later transition to active without errors. Add a FIXME to remind people that we're doing

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm: Add aux plane verification in addFB2 (rev2)

== Series Details == Series: series starting with [1/2] drm: Add aux plane verification in addFB2 (rev2) URL : https://patchwork.freedesktop.org/series/4641/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/igb/e1000_nvm.o CC [M]

[Intel-gfx] [PATCH 1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk

From: Ville Syrjälä Use the cdclk we're going to be using when the pipe gets enabled to compute the IPS linetime watermark. The current cdclk frequency is irrelevant at this point since it can still change. Cc: Maarten Lankhorst

[Intel-gfx] [PATCH v2 2/2] drm/i915: Render decompression support for Gen9 and above

This patch includes enabling render decompression (RC) after checking all the requirements (format, tiling, rotation etc.). TODO: 1. Disable stereo 3D when render decomp is enabled (bit 7:6) 2. Render decompression must not be used in VTd pass-through mode 3. Program hashing select CHICKEN_MISC1

Re: [Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV

On Fri, 29 Apr 2016, Ville Syrjälä wrote: > On Fri, Apr 29, 2016 at 03:34:03PM +0300, Jani Nikula wrote: >> VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use >> the border enable software state for anything, so don't set it >> either. This

Re: [Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV

On Fri, Apr 29, 2016 at 03:34:03PM +0300, Jani Nikula wrote: > VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use > the border enable software state for anything, so don't set it > either. This should avoid a state checker warning on lvds_border_bits, > although one hasn't been

Re: [Intel-gfx] [PATCH 1/2] drm/i915/lvds: separate border enable readout from panel fitter

On Fri, Apr 29, 2016 at 03:34:02PM +0300, Jani Nikula wrote: > The LVDS border enable is independent from the panel fitter. Move the > readout of the "border bits" from i9xx_get_pfit_config() to > intel_lvds_get_config(), where it will be read if LVDS is enabled even > if the panel fitter is not.

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/lvds: separate border enable readout from panel fitter

== Series Details == Series: series starting with [1/2] drm/i915/lvds: separate border enable readout from panel fitter URL : https://patchwork.freedesktop.org/series/6535/ State : success == Summary == Series 6535v1 Series without cover letter

[Intel-gfx] [PATCH i-g-t 2/2] autotools, assembler: Fix check target for tests in assembler.

assembler suffers from the same issue as lib/tests, adjust it so it allows us to do a check. Have to make autotools happy by having an empty Makefile.am. Signed-off-by: Marius Vlad --- assembler/Makefile.am | 108 -

[Intel-gfx] [PATCH i-g-t 1/2] autotools: Check target requires to a have the list of tests built.

We need to have the test list generated before running the check target. Migrated igt_command_line.sh to tests/ from lib/tests/, which allows to building the tests and execute the script. This would allow cleaning followed by a make check. Signed-off-by: Marius Vlad ---

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

== Series Details == Series: series starting with [CI,1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy URL : https://patchwork.freedesktop.org/series/6534/ State : success == Summary == Series 6534v1 Series without cover letter

Re: [Intel-gfx] [PATCH 05/19] drm/i915: Unify unpin_work and mmio_work into flip_work.

On Tue, Apr 19, 2016 at 09:52:25AM +0200, Maarten Lankhorst wrote: > Rename intel_unpin_work to intel_flip_work and use it for mmio flips > and unpinning. Use flip_queued_req to hold the wait request in the > mmio case, and the vblank counter from intel_crtc_get_vblank_counter. > > Signed-off-by:

[Intel-gfx] [PATCH i-g-t] tools/intel_watermark: Dump linetime watermarks on hsw/bdw

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- tools/intel_watermark.c | 46 -- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/tools/intel_watermark.c

Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

On Fri, 29 Apr 2016, Ville Syrjälä wrote: > On Fri, Apr 29, 2016 at 01:12:33PM +0300, Ville Syrjälä wrote: >> On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote: >> > We also don't read the border bits in i9xx_get_pfit_config() when the >> > panel fitter is

[Intel-gfx] [PATCH 1/2] drm/i915/lvds: separate border enable readout from panel fitter

The LVDS border enable is independent from the panel fitter. Move the readout of the "border bits" from i9xx_get_pfit_config() to intel_lvds_get_config(), where it will be read if LVDS is enabled even if the panel fitter is not. This fixes the state checker warning:

[Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV

VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use the border enable software state for anything, so don't set it either. This should avoid a state checker warning on lvds_border_bits, although one hasn't been spotted in the wild. Signed-off-by: Jani Nikula

[Intel-gfx] [CI 2/5] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

The i915.enable_ppgtt option depends upon the state of i915.enable_execlists option - so we need to sanitize execlists first. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_dma.c | 13

[Intel-gfx] [CI 5/5] drm/i915: Reload PD tables after semaphore wait on gen8

When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by: Chris Wilson Cc: Ville Syrjälä

[Intel-gfx] [CI 4/5] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä

[Intel-gfx] [CI 1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

For legacy ringbuffer mode, we need the new ordered breadcrumb emission tried and tested on execlists in order to avoid the dreaded "missed interrupt" syndrome. A secondary advantage of the execlists method is that it writes to an arbitrary address, useful if one wants to write a breadcrumb

[Intel-gfx] [CI 3/5] drm/i915: Fix gen8 semaphores id for legacy mode

With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add360522c876c25ef2ab1c94bdb509ab Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

On Fri, Apr 29, 2016 at 01:12:33PM +0300, Ville Syrjälä wrote: > On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote: > > We also don't read the border bits in i9xx_get_pfit_config() when the > > panel fitter is not enabled, causing the state checker warning: > > > >

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

== Series Details == Series: series starting with [CI,1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy URL : https://patchwork.freedesktop.org/series/6532/ State : warning == Summary == Series 6532v1 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/gem: support BO freeing without dev->struct_mutex

On Fri, Apr 29, 2016 at 11:18:18AM -, Patchwork wrote: > == Series Details == > > Series: drm/gem: support BO freeing without dev->struct_mutex > URL : https://patchwork.freedesktop.org/series/6527/ > State : failure > > == Summary == > > Series 6527v1 drm/gem: support BO freeing without

[Intel-gfx] [CI 6/7] drm/i915: Enable semaphores for legacy submission on gen8

We have sufficient evidence from igt to support that semaphores are in a working state. Enabling semaphores now for legacy provides a better comparison of execlists against legacy ring submission. Signed-off-by: Chris Wilson Acked-by: Daniel Vetter

[Intel-gfx] [CI 7/7] drm/i915: Enable legacy/semaphores for CI

--- drivers/gpu/drm/i915/intel_lrc.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index d8763524319d..0713acb52ce4 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -260,10 +260,6

[Intel-gfx] [CI 2/7] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

The i915.enable_ppgtt option depends upon the state of i915.enable_execlists option - so we need to sanitize execlists first. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_dma.c | 13

[Intel-gfx] [CI 5/7] drm/i915: Reload PD tables after semaphore wait on gen8

When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by: Chris Wilson Cc: Ville Syrjälä

[Intel-gfx] [CI 4/7] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal

In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by: Chris Wilson Reviewed-by: Ville Syrjälä

[Intel-gfx] [CI 1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy

For legacy ringbuffer mode, we need the new ordered breadcrumb emission tried and tested on execlists in order to avoid the dreaded "missed interrupt" syndrome. A secondary advantage of the execlists method is that it writes to an arbitrary address, useful if one wants to write a breadcrumb

[Intel-gfx] [CI 3/7] drm/i915: Fix gen8 semaphores id for legacy mode

With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add360522c876c25ef2ab1c94bdb509ab Signed-off-by: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lvds: do not set border bits when panel fitter is not enabled

== Series Details == Series: drm/i915/lvds: do not set border bits when panel fitter is not enabled URL : https://patchwork.freedesktop.org/series/6530/ State : success == Summary == Series 6530v1 drm/i915/lvds: do not set border bits when panel fitter is not enabled

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/gem: support BO freeing without dev->struct_mutex

== Series Details == Series: drm/gem: support BO freeing without dev->struct_mutex URL : https://patchwork.freedesktop.org/series/6527/ State : failure == Summary == Series 6527v1 drm/gem: support BO freeing without dev->struct_mutex

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On Fri, Apr 29, 2016 at 11:56:28AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 11:39, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote: > >> > >>On 29/04/16 11:18, Chris Wilson wrote: > >>>On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

On to, 2016-04-28 at 17:24 +0100, Chris Wilson wrote: > The i915.enable_ppgtt option depends upon the state of > i915.enable_execlists option - so we need to sanitize execlists first. > Reviewed-by: Joonas Lahtinen > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On 29/04/16 11:39, Chris Wilson wrote: On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote: On 29/04/16 11:18, Chris Wilson wrote: On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: I don't get it - if we are adding something why not add it in a way that makes it

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 11:18, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: > >>I don't get it - if we are adding something why not add it in a way > >>that makes it clear and self-contained - what

Re: [Intel-gfx] i915 ERRORs and WARN_ON()s

On Fri, Apr 29, 2016 at 04:27:08AM +0200, Florian Zumbiehl wrote: > Hi, > > > The Bugzilla at https://bugs.freedesktop.org is our tool of choice for > > tracking bugs in drm/i915. It's your choice to not create an account > > there, but please, don't expect us to work as a proxy between you and >

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On 29/04/16 11:18, Chris Wilson wrote: On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: I don't get it - if we are adding something why not add it in a way that makes it clear and self-contained - what is the downside of what I propose to meet such resistance? You're

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 11:11:20AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 11:00, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote: > >> > >>On 29/04/16 10:39, Chris Wilson wrote: > >>>On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: >

[Intel-gfx] ✗ Fi.CI.BAT: failure for Support blending modes of display planes (rev2)

== Series Details == Series: Support blending modes of display planes (rev2) URL : https://patchwork.freedesktop.org/series/2582/ State : failure == Summary == Series 2582v2 Support blending modes of display planes http://patchwork.freedesktop.org/api/1.0/series/2582/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: > I don't get it - if we are adding something why not add it in a way > that makes it clear and self-contained - what is the downside of > what I propose to meet such resistance? You're suggesting to add a field I'm not going to use.

Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote: > We also don't read the border bits in i9xx_get_pfit_config() when the > panel fitter is not enabled, causing the state checker warning: > > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in > gmch_pfit.lvds_border_bits

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On 29/04/16 11:00, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote: On 29/04/16 10:39, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: On 29/04/16 10:15, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/intel_lrc.c

Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space

On 28/04/16 11:24, Chris Wilson wrote: On Thu, Apr 28, 2016 at 10:30:32AM +0100, Tvrtko Ursulin wrote: On 26/04/16 10:44, Chris Wilson wrote: On Mon, Apr 25, 2016 at 03:51:09PM +0100, Tvrtko Ursulin wrote: On 25/04/16 11:35, Ankitprasad Sharma wrote: On Thu, 2016-04-21 at 15:59 +0100,

Re: [Intel-gfx] [PATCHv2 1/5] drm: Introduce the blend-func property

On Fri, Apr 29, 2016 at 02:59:13PM +0530, Vandita Kulkarni wrote: > From: Damien Lespiau > > We'd like to be able to program the blending modes of display planes. > Ville suggested to use something similar to the GL blend states, which > does seem like a good idea. > >

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 10:39, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > >>On 29/04/16 10:15, Chris Wilson wrote: > >>>diff --git a/drivers/gpu/drm/i915/intel_lrc.c >

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On 29/04/16 10:39, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: On 29/04/16 10:15, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 2e0eaa9fa240..2c94072ab085 100644 ---

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > Not the most elegant because all the hw access we have so far is in > engine->init_hw. Why can't we just make intel_engine_initialized > return false until the very last thing in engine constructors? The other thing I've been

Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early

On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > I'd like to propose that we push the i915 suspend_late/resume_early code > into suspend_noirq/resume_noirq in order to reduce the total suspend time > by ~15ms. According to the comments, when i915_pm_suspend_late was first >

[Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled

We also don't read the border bits in i9xx_get_pfit_config() when the panel fitter is not enabled, causing the state checker warning: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 0x8000, found 0x) Cc: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > On 29/04/16 10:15, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >b/drivers/gpu/drm/i915/intel_lrc.c > >index 2e0eaa9fa240..2c94072ab085 100644 > >--- a/drivers/gpu/drm/i915/intel_lrc.c > >+++

Re: [Intel-gfx] [PATCH 21/21] drm/i915/slpc: Fail intel_runtime_suspend if SLPC or RPS not active

On to, 2016-04-28 at 09:00 +0100, Chris Wilson wrote: > On Thu, Apr 28, 2016 at 10:57:20AM +0300, Imre Deak wrote: > > On to, 2016-04-28 at 07:56 +0100, Chris Wilson wrote: > > > On Wed, Apr 27, 2016 at 06:11:05PM -0700, tom.orou...@intel.com > > > wrote: > > > > From: Sagar Arun Kamble

[Intel-gfx] [PATCH] drm/gem: support BO freeing without dev->struct_mutex

Finally all the core gem and a lot of drivers are entirely free of dev->struct_mutex depencies, and we can start to have an entirely lockless unref path. To make sure that no one who touches the core code accidentally breaks existing drivers which still require dev->struct_mutex I've made the

Re: [Intel-gfx] [PATCH] mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly

On Fri, Apr 22, 2016 at 9:38 PM, wrote: > From: Ville Syrjälä > > GPIO lookup tables are supposed to be zero terminated. Let's do that > and avoid accidentally walking off the end. > > Cc: Shobhit Kumar >

[Intel-gfx] [PATCHv2 1/5] drm: Introduce the blend-func property

From: Damien Lespiau We'd like to be able to program the blending modes of display planes. Ville suggested to use something similar to the GL blend states, which does seem like a good idea. For now, we only consider blend factors, but room is left for extensions: blend

[Intel-gfx] [PATCHv2 4/5] drm: Add an blend_color property

From: Damien Lespiau Add blend color property and update the documentation for the same V2: Add blend color support in get property. Signed-off-by: Damien Lespiau Signed-off-by: vandita kulkarni ---

[Intel-gfx] [PATCHv2 5/5] drm/i915/skl: Add support for blending modes

From: Damien Lespiau This patch adds support for blending modes involving color. V2: Add support for primary plane. Separate out plane alpha disable functionality from per pixel drop_alpha blend function and add another blend function case for disabling plane alpha.

[Intel-gfx] [PATCHv2 0/5] Support blending modes of display planes

From: vandita kulkarni The below patches support plane and pixel blending by adding two properties blend_func and blend_color. As per Damien's initial patches, this design based on OpenGL's blend equations is suggested by Ville. All the below patches are tested on

[Intel-gfx] [PATCHv2 2/5] drm/i915/skl: Add blend_func to SKL/BXT sprite planes

From: Damien Lespiau This patch adds the blend functions, and as per the blend function, updates the plane control register values V2: Add blend support for all RGB formats Fix the reg writes on plane_ctl_alpha bits. V3: Add support support for primary and cursor

[Intel-gfx] [PATCHv2 3/5] drm: Introduce DRM_MODE_COLOR()

From: Damien Lespiau In the hope of expressing colors in the KMS API in a consitant want, let's introduce a ARGB 16161616 color and a few convinience macros around it. Signed-off-by: Damien Lespiau --- include/uapi/drm/drm_mode.h | 34

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On 29/04/16 10:15, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:04:35AM +0100, Tvrtko Ursulin wrote: On 28/04/16 18:35, Chris Wilson wrote: Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Bump reserved size for legacy gen8 semaphore emission

== Series Details == Series: series starting with [CI,1/3] drm/i915: Bump reserved size for legacy gen8 semaphore emission URL : https://patchwork.freedesktop.org/series/6523/ State : success == Summary == Series 6523v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Fri, Apr 29, 2016 at 10:04:35AM +0100, Tvrtko Ursulin wrote: > > On 28/04/16 18:35, Chris Wilson wrote: > >Move all of the constant assignments up front and into a common > >function. This is primarily to ensure the backpointers are set as early > >as possible for later use during

Re: [Intel-gfx] [PATCH 15/21] drm/i915/slpc: Notification of Refresh Rate change

On Wed, Apr 27, 2016 at 06:10:59PM -0700, tom.orou...@intel.com wrote: > From: Sagar Arun Kamble > > This patch will inform GuC SLPC about changes in the refresh rate > due to Seamless DRRS. Refresh rate changes due to Static DRRS will > be notified via commit path. >

  1   2   >